Date: Tue, 9 Dec 2008 19:53:27 +0300
From: "Vladimir '3APA3A' Dubrovin" <3APA3A@...URITY.NNOV.RU>
To: bruhns@...urity-labs.com
Cc: bugtraq@...urityfocus.com
Subject: Re: DoS attacks on MIME-capable software via complex MIME emails

Dear bruhns@...urity-labs.com,

Idea  is  not new. Same vulnerabilit was reported for Agnitum Outpost by
Alexander Andrusenko in 2004, http://securityvulns.com/news3687.html

Also,   same   vulnerabilities  were  reported  and  fixed  in  Sendmail
(CVE-2006-1173).

--Tuesday, December 9, 2008, 1:52:17 AM, you wrote to bugtraq@...urityfocus.com:

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@...l>
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@...l>;
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@...l>
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 15.5.0.23
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> RFC2045_ERR2COMPLEX
brlc>     The message has too many MIME sections, this is a potential
brlc> denial-of-service attack.
brlc> RFC2045_ERRBADBOUNDARY
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 secunia.com/advisories/11360/
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: http://www.recurity-labs.com
brlc> Email-address: bruhns@...urity-labs.com
brlc> Wiki for further problem discussion: http://mime.recurity.com

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

brlc> Cheers,
brlc> Bruhns




-- 
~/ZARAZA http://securityvulns.com/
Появился новый тип элементарных частиц - шкварки.
Не очень большие, слегка подгоревшие.  (Лем)

Powered by blists - more mailing lists