== 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: <bruhns@hell> To: <foo@bar> 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: <bruhns@hell>; 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: <bruhns@hell> To: <foo@bar> 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: bruhns (at) recurity-labs (dot) com [email concealed] Wiki for further problem discussion: http://mime.recurity.com Thanks to FX, Fabs and joern for various help. Cheers, Bruhns