== DoS attacks on MIME-capable software via complex MIME emails ===0D
=0D
== Preface ===0D
On the phneutral 0x7d8 and RSS 08, I gave short talks on a widely unregarded=0D
problem with MIME software. Due to popular demand, I decided to publish a=0D
short writeup of the talk.=0D
=0D
== What is MIME? ===0D
MIME is the standard format for email-messages. One could say, MIME is for=0D
email, what html is for the web. The first RFC for MIME was published in=0D
1992, RFC 1341. The current standard is specified in RFC 2045 from 1996.=0D
MIME is a recursive data format. MIME objects consist of a header and a=0D
body, where the content-type field of the header specifies the type of the=0D
body. The body can consist of several separated MIME-objects, a single=0D
MIME-object, a block of text, an encoded image or about anything specified=0D
in the header. It is possible to read some real-world examples by opening=0D
some emails and hitting "show source".=0D
=0D
== Two examples to illustrate MIME ===0D
The first example is the content-type:message/rfc822, which is intended for=0D
forwarding emails. The following body is a complete email, which starts=0D
again with a header, followed by a body. The second example is the=0D
content-type:multipart/mixed. A pretty much self-explanatory example is=0D
provided below. The parts of the body are separated by strcat("--",=0D
boundary) and the body must be ended by strcat("--", boundary, "--").=0D
=0D
From: =0D
To: =0D
Subject: example=0D
MIME-Version: 1.0=0D
Content-Type: multipart/mixed; boundary="n"=0D
=0D
--n=0D
content-type:text/plain=0D
=0D
this is some plain text.=0D
--n=0D
content-type:message/rfc822=0D
=0D
From: ;=0D
Subject: example 2=0D
=0D
This is not a MIME-mail, since the mime-version field is missing! However,=0D
most software does not care.=0D
--n--=0D
=0D
== The problem ===0D
Even though MIME is pretty old, many people have not yet learned how to=0D
parse MIME correctly. The problem is that the number of MIME-parts of an=0D
email and the depth of recursion is potentially unlimited. Some software=0D
like the popular rfc2045 library of the courier-mta solve this problem by=0D
discarding mails with too many MIME-parts as a Denial of Service attack.=0D
This is probably the best approach to handle this problem.=0D
=0D
== Proof-of-Concept: Nesty ===0D
The nesty attack abuses the message/rfc822 type. The following example=0D
crashes a lot of software, which tries to parse it recursively and=0D
therefore overflows its stack:=0D
=0D
Content-type: message/rfc822;=0D
=0D
Content-type: message/rfc822;=0D
=0D
Content-type: message/rfc822;=0D
=0D
Content-type: message/rfc822;=0D
=0D
... about 200kb. Note that this mail is not compliant to the rfc2045, since=0D
the mime-version field is missing. However, most software does not care and=0D
a lot of it chokes on this mail. In order to attack more rfc-abiding=0D
software (mostly open-source), one can easily adapt the nesty mail to be=0D
compliant. This however increases the size of the mail considerably, which=0D
somehow takes away the elegance of crashing a server with only 200kb.=0D
=0D
=0D
== Proof-of-Concept: Multikill ===0D
The multikill attack abuses the multipart/mixed type by creating an overly=0D
large number of MIME-parts. Multipart/mixed could be used in a recursive=0D
way, but this is not even needed for this attack. A lot of software freezes=0D
upon the following example:=0D
=0D
From: =0D
To: =0D
Subject: multikill=0D
MIME-Version: 1.0=0D
Content-Type: multipart/mixed; boundary="n"=0D
=0D
=0D
--n=0D
=0D
b=0D
=0D
--n=0D
=0D
... about 800kb or 70000 parts. For a lot of software, about 216 seems to=0D
be the barrier, so you can't craft much more compact multikill attacks.=0D
=0D
--n=0D
=0D
b=0D
=0D
--n--=0D
=0D
== Impact ===0D
Firstly, the attack is DoS only. At this point it seems rather unlikely,=0D
that command execution can be crafted on the basis of this problem.=0D
However, the DoS vulnerability exposed by these proof-of-concept mails is=0D
shared by many systems by different vendors and is trivial to exploit. The=0D
ramnifications of this attack are therefore not really known yet. There is=0D
still much testing to do.=0D
=0D
And at last, there does not only exist a problem with emails with to many=0D
MIME parts, but there exists a whole problem class and a whole class of=0D
attacks, which are insufficiently researched and regarded by now. Of these=0D
attacks, DoS via malformed MIME emails, the nesty and multikill mails are=0D
only the first examples, the tip of the iceberg, so to say; once software=0D
has been patched to correctly handle these emails, other people will come=0D
up with other examples of malformed emails. To look at this attack even=0D
more broadly, the topic of DoS attacks via overly complex instances of=0D
recursive data types is not researched sufficiently.=0D
=0D
== Effects on Outlook Express ===0D
Outlook freezes on the multikill mail. Outlook starts parsing emails while=0D
downloading them. Upon parsing a multikill mail with more than about 216=0D
parts, some library function goes into an endless loop. Outlook never=0D
finishes downloading the multikill mail, it stays in the mailbox. Outlook=0D
never closes the connection to the mail server, which is not nice to the=0D
mailserver. Outlook can only be stopped by killing the process from the=0D
task manager.=0D
=0D
To be more exact, the bug seems to reside in InetComm.dll in the=0D
MimeOleClearDirtyTree function. I would guess at a short-integer overflow,=0D
which results in the infinite loop.=0D
=0D
Microsoft was informed on 29.07.08 and declined to comment on this issue.=0D
=0D
== Effects on Virusscanners ===0D
NOD32 takes several minutes of kerneltime to scan the multikill mails. ESET=0D
did not comment on this issue and was informed on 01.08.08.=0D
Kaspersky Internet Security Suite takes several minutes to scan the=0D
multikill mail. Kaspersky was informed on 29.07.08, confirmed the issue and=0D
promised to fix the problem.=0D
Norton Antivirus takes several minutes to scan the multikill mails. Norton=0D
was informed on informed 01.08.08 and answered promptly and politely.=0D
Norton promised not to fix the problem, since it would not qualify as a=0D
Denial of Service vulnerability.=0D
=0D
=0D
== Specific Software ===0D
Vulnerable:=0D
Microsoft Outlook Express 6, Version 6.00.2900.5512=0D
Opera Version: 9.51 Build: 10081 System: Windows XP=0D
Incredimail Build ID: 5853710 Setup ID: 7 Pn: 92977368=0D
Norton Internet Security Version 15.5.0.23=0D
ESet NOD32 2.70.0039.0000=0D
Kaspersky Internet Security 2009; Databases from 23.07.2008=0D
=0D
Slightly affected:=0D
Mozilla Thunderbird Version 2.0.14 (20080421)=0D
=0D
Not vulnerable:=0D
Avira Antivir Search engine: v8.01.01.11, 17.07.2008=0D
Mutt=0D
Courier=0D
=0D
== Correct handling of overly complex messages= ===0D
There exist examples of software, which excellently handles overly complex=0D
MIME-mails. One is the rfc2045 -library of the courier-mta. Quote from the=0D
man 3 rfc2045:=0D
=0D
The rfcviolation field in the top-level rfc2045 indicates any errors found=0D
while parsing the MIME message.=0D
 rfcviolation is a bitmask of the following flags:=0D
=0D
[...]=0D
RFC2045_ERR2COMPLEX=0D
    The message has too many MIME sections, this is a potential=0D
denial-of-service attack.=0D
RFC2045_ERRBADBOUNDARY=0D
    Ambiguous nested multipart MIME boundary strings. (Nested MIME boundary=0D
strings where one string is a prefix of another string).=0D
=0D
Inspection of the source code reveals, that the parser of the courier-mta=0D
allows only 300 mime parts and a nesting depth of 30 levels. Since courier=0D
seems not to get too many complaints, this is probably a reasonable limit.=0D
=0D
== History of this bug ===0D
I (re)discovered the bug independently in mid 2007. The bug was however=0D
known before. There are some advisories like secunia.com/advisories/11360/=0D
(for Eudora, bug still unfixed) by people who discovered the problem=0D
before, but did not publicly announce or did not see the scope of it. More=0D
recently, there has been a likewise advisory for sendmail, CVE-2006-1173.=0D
There have been other advisories for different antivirus solutions. This=0D
bug is not 0-day at all, it is really old. If you find older advisories,=0D
which cover this bug, or knew it before, mail me so I can update this=0D
section.=0D
=0D
== Credit ===0D
This bug was discovered by Bernhard 'Bruhns' Brehm at Recurity Labs.=0D
Company page: http://www.recurity-labs.com=0D 
Email-address: bruhns@recurity-labs.com=0D 
Wiki for further problem discussion: http://mime.recurity.com=0D 
=0D
Thanks to FX, Fabs and joern for various help.=0D
=0D
Cheers,=0D
Bruhns=0D
=0D
=0D
=0D