Re: DoS attacks on MIME-capable software via complex MIME emails

From: Vladimir '3APA3A' Dubrovin <3APA3A@SECURITY.NNOV.RU>
Subject: Re: DoS attacks on MIME-capable software via complex MIME emails


Idea  is  not new. Same vulnerabilit was reported for Agnitum Outpost by
Alexander Andrusenko in 2004,

Also,   same   vulnerabilities  were  reported  and  fixed  in  Sendmail

--Tuesday, December 9, 2008, 1:52:17 AM, you wrote to

brlc> == DoS attacks on MIME-capable software via complex MIME emails ==

brlc> == Preface ==
brlc> On the phneutral 0x7d8 and RSS 08, I gave short talks on a widely unregarded
brlc> problem with MIME software. Due to popular demand, I decided to publish a
brlc> short writeup of the talk.

brlc> == What is MIME? ==
brlc> MIME is the standard format for email-messages. One could say, MIME is for
brlc> email, what html is for the web. The first RFC for MIME was published in
brlc> 1992, RFC 1341. The current standard is specified in RFC 2045 from 1996.
brlc> MIME is a recursive data format. MIME objects consist of a header and a
brlc> body, where the content-type field of the header specifies the type of the
brlc> body. The body can consist of several separated MIME-objects, a single
brlc> MIME-object, a block of text, an encoded image or about anything specified
brlc> in the header. It is possible to read some real-world examples by opening
brlc> some emails and hitting "show source".

brlc> == Two examples to illustrate MIME ==
brlc> The first example is the content-type:message/rfc822, which is intended for
brlc> forwarding emails. The following body is a complete email, which starts
brlc> again with a header, followed by a body. The second example is the
brlc> content-type:multipart/mixed. A pretty much self-explanatory example is
brlc> provided below. The parts of the body are separated by strcat("--",
brlc> boundary) and the body must be ended by strcat("--", boundary, "--").

brlc> From: <bruhns@hell>
brlc> To: <foo@bar>
brlc> Subject: example
brlc> MIME-Version: 1.0
brlc> Content-Type: multipart/mixed; boundary="n"

brlc> --n
brlc> content-type:text/plain

brlc> this is some plain text.
brlc> --n
brlc> content-type:message/rfc822

brlc> From: <bruhns@hell>;
brlc> Subject: example 2

brlc> This is not a MIME-mail, since the mime-version field is missing! However,
brlc> most software does not care.
brlc> --n--

brlc> == The problem ==
brlc> Even though MIME is pretty old, many people have not yet learned how to
brlc> parse MIME correctly. The problem is that the number of MIME-parts of an
brlc> email and the depth of recursion is potentially unlimited. Some software
brlc> like the popular rfc2045 library of the courier-mta solve this problem by
brlc> discarding mails with too many MIME-parts as a Denial of Service attack.
brlc> This is probably the best approach to handle this problem.

brlc> == Proof-of-Concept: Nesty ==
brlc> The nesty attack abuses the message/rfc822 type. The following example
brlc> crashes a lot of software, which tries to parse it recursively and
brlc> therefore overflows its stack:

brlc> Content-type: message/rfc822;

brlc> Content-type: message/rfc822;

brlc> Content-type: message/rfc822;

brlc> Content-type: message/rfc822;

brlc> ... about 200kb. Note that this mail is not compliant to the rfc2045, since
brlc> the mime-version field is missing. However, most software does not care and
brlc> a lot of it chokes on this mail. In order to attack more rfc-abiding
brlc> software (mostly open-source), one can easily adapt the nesty mail to be
brlc> compliant. This however increases the size of the mail considerably, which
brlc> somehow takes away the elegance of crashing a server with only 200kb.

brlc> == Proof-of-Concept: Multikill ==
brlc> The multikill attack abuses the multipart/mixed type by creating an overly
brlc> large number of MIME-parts. Multipart/mixed could be used in a recursive
brlc> way, but this is not even needed for this attack. A lot of software freezes
brlc> upon the following example:

brlc> From: <bruhns@hell>
brlc> To: <foo@bar>
brlc> Subject: multikill
brlc> MIME-Version: 1.0
brlc> Content-Type: multipart/mixed; boundary="n"

brlc> --n

brlc> b

brlc> --n

brlc> ... about 800kb or 70000 parts. For a lot of software, about 216 seems to
brlc> be the barrier, so you can't craft much more compact multikill attacks.

brlc> --n

brlc> b

brlc> --n--

brlc> == Impact ==
brlc> Firstly, the attack is DoS only. At this point it seems rather unlikely,
brlc> that command execution can be crafted on the basis of this problem.
brlc> However, the DoS vulnerability exposed by these proof-of-concept mails is
brlc> shared by many systems by different vendors and is trivial to exploit. The
brlc> ramnifications of this attack are therefore not really known yet. There is
brlc> still much testing to do.

brlc> And at last, there does not only exist a problem with emails with to many
brlc> MIME parts, but there exists a whole problem class and a whole class of
brlc> attacks, which are insufficiently researched and regarded by now. Of these
brlc> attacks, DoS via malformed MIME emails, the nesty and multikill mails are
brlc> only the first examples, the tip of the iceberg, so to say; once software
brlc> has been patched to correctly handle these emails, other people will come
brlc> up with other examples of malformed emails. To look at this attack even
brlc> more broadly, the topic of DoS attacks via overly complex instances of
brlc> recursive data types is not researched sufficiently.

brlc> == Effects on Outlook Express ==
brlc> Outlook freezes on the multikill mail. Outlook starts parsing emails while
brlc> downloading them. Upon parsing a multikill mail with more than about 216
brlc> parts, some library function goes into an endless loop. Outlook never
brlc> finishes downloading the multikill mail, it stays in the mailbox. Outlook
brlc> never closes the connection to the mail server, which is not nice to the
brlc> mailserver. Outlook can only be stopped by killing the process from the
brlc> task manager.

brlc> To be more exact, the bug seems to reside in InetComm.dll in the
brlc> MimeOleClearDirtyTree function. I would guess at a short-integer overflow,
brlc> which results in the infinite loop.

brlc> Microsoft was informed on 29.07.08 and declined to comment on this issue.

brlc> == Effects on Virusscanners ==
brlc> NOD32 takes several minutes of kerneltime to scan the multikill mails. ESET
brlc> did not comment on this issue and was informed on 01.08.08.
brlc> Kaspersky Internet Security Suite takes several minutes to scan the
brlc> multikill mail. Kaspersky was informed on 29.07.08, confirmed the issue and
brlc> promised to fix the problem.
brlc> Norton Antivirus takes several minutes to scan the multikill mails. Norton
brlc> was informed on informed 01.08.08 and answered promptly and politely.
brlc> Norton promised not to fix the problem, since it would not qualify as a
brlc> Denial of Service vulnerability.

brlc> == Specific Software ==
brlc> Vulnerable:
brlc> Microsoft Outlook Express 6, Version 6.00.2900.5512
brlc> Opera Version: 9.51 Build: 10081 System: Windows XP
brlc> Incredimail Build ID: 5853710 Setup ID: 7 Pn: 92977368
brlc> Norton Internet Security Version
brlc> ESet NOD32 2.70.0039.0000
brlc> Kaspersky Internet Security 2009; Databases from 23.07.2008

brlc> Slightly affected:
brlc> Mozilla Thunderbird Version 2.0.14 (20080421)

brlc> Not vulnerable:
brlc> Avira Antivir Search engine: v8.01.01.11, 17.07.2008
brlc> Mutt
brlc> Courier

brlc> == Correct handling of overly complex messages= ==
brlc> There exist examples of software, which excellently handles overly complex
brlc> MIME-mails. One is the rfc2045 -library of the courier-mta. Quote from the
brlc> man 3 rfc2045:

brlc> The rfcviolation field in the top-level rfc2045 indicates any errors found
brlc> while parsing the MIME message.
brlc>  rfcviolation is a bitmask of the following flags:

brlc> [...]
brlc>     The message has too many MIME sections, this is a potential
brlc> denial-of-service attack.
brlc>     Ambiguous nested multipart MIME boundary strings. (Nested MIME boundary
brlc> strings where one string is a prefix of another string).

brlc> Inspection of the source code reveals, that the parser of the courier-mta
brlc> allows only 300 mime parts and a nesting depth of 30 levels. Since courier
brlc> seems not to get too many complaints, this is probably a reasonable limit.

brlc> == History of this bug ==
brlc> I (re)discovered the bug independently in mid 2007. The bug was however
brlc> known before. There are some advisories like
brlc> (for Eudora, bug still unfixed) by people who discovered the problem
brlc> before, but did not publicly announce or did not see the scope of it. More
brlc> recently, there has been a likewise advisory for sendmail, CVE-2006-1173.
brlc> There have been other advisories for different antivirus solutions. This
brlc> bug is not 0-day at all, it is really old. If you find older advisories,
brlc> which cover this bug, or knew it before, mail me so I can update this
brlc> section.

brlc> == Credit ==
brlc> This bug was discovered by Bernhard 'Bruhns' Brehm at Recurity Labs.
brlc> Company page:
brlc> Email-address:
brlc> Wiki for further problem discussion:

brlc> Thanks to FX, Fabs and joern for various help.

brlc> Cheers,
brlc> Bruhns

     - .
  ,  .  ()

Copyright © 1995-2020 All rights reserved.