Dear bruhns@xxxxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxxxx: 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 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@xxxxxxxxxxxxxxxxx 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/ Появился новый тип элементарных частиц - шкварки. Не очень большие, слегка подгоревшие. (Лем)
