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