NYCPHP Meetup

[Hans Zaunere]

David Mintz scribbled on Wednesday, September 14, 2005 11:20 AM:
> On Wed, 14 Sep 2005, Hans Zaunere wrote:
> > > 
> > > So it would seem if you ventured past the parts of the JavaMail
> > > API which allow you to use Strings, instead of creating
> > > InternetAddress objects and hardcoding the subject, you would be
> > > "safe" from the exploit, but you should double check any methods
> > > that you are using that expect Strings.
> > 
> > Good point - looks like justification for a wrapper class for the
> > mail() function in PHP. 
> > 
> > We're working on getting a Phundamentals article online covering the
> > discussion over the last couple of days.  Thanks Roland and
> > everyone for their feedback and discussion.
> 
> And that class would sanitize message headers only, or the body as
> well? I am still unclear whether evil stuff in the body can spawn a
> completely new message.

That class - if it existed :) - would sanitize any user input before
entering the mail() function - ie, anything that could get into the header.

The basic premise of this exploit is leveraging the MIME and SMTP standards,
not PHP.  As we've discussed and Dan Krook pointed out, some languages like
Java have specific classes that are meant to wrap what is passed into a mail
message.  This is essentially what a wrapper class in PHP would do.  If,
however, these classes are not used - and generic strings are used - then
it's likely that any web form is vulnerable.

The reason for this is how the MIME standard works, and thus how SMTP
interprets MIME messages.  A basic MIME message is broken into two parts; a
header and a body.  The header and body are separated by a blank line, ie,
\r\n\r\n (although most mail clients will accept UNIX and other line
deliminaters, like \n\n or even \n\r\n\r).

Another aspect of MIME is multi-part, which is where the fun comes in.  This
means that messages can be embedded in other messages.  This is done by
having the top level header declare a boundary, which is then used to
process further header/body pairs.

If someone is able to inject content into this top level header, they can
now essentially control the structure of the entire message.  This is done
by creating their own boundary, thus defining what's a body and what's a
header.

The other significant point of weakness that's taken advantage of is the
fact that MIME (and sub sequentially really SMTP in this case) can deal with
multiple headers of the same name.  Meaning, if there is a To: followed by a
To: they are interpreted "correctly" (ie, no error is thrown).

Putting it all together, this allows an attacker to define additional
recipients for a message, not to mention adding Bcc: and Cc: headers (using
multiple headers of the same name), and additionally then defining body
parts to be sent as the content of the message (by defining a multi-part
message).

So the upshot:  filter/sanitize anything that can get into the top-level
header and you're safe - from this exploit anyway.

An ingenuous hack really; by combining innocuous - and frankly useful -
features of MIME/SMTP, they were able to create a security problem.  But
then again, isn't that what security is always about?  :)


---
Hans Zaunere / President / New York PHP
   www.nyphp.org  /  www.nyphp.com