Re: [Full-disclosure] DoS attacks on MIME-capable software via complex MIME emails
[EMAIL PROTECTED] said: You want *real* loads of fun? Go read up on message/partial ;) You're right. The RFCs do read like fun. I did some testing on DoS attacks with message/partial before I found the other problems. However, most applications refuse to reassemble messages. The situation is quite similiar to the reason, why MTAs like sendmail are no real target for such attacks: No server should try to convert 8bit encoding to 7bit encoding any more. Nobody needs to split a message into several parts for transfer and expects the mailclient to reassemble the parts. Not all pieces of MIME-related software really need to understand these rather obscure content-types. Another grateful target is multipart/related (rfc2387) in combination with text/html. Once the problems with nesting and overly large multiparts are resolved, you will want to look there for more bugs. One type of attacks to be found there is to cause quadratic or worse memory consumption at the target (quadratic with respect to the email size)- quite similiar to Fefe's 42.zip or all these webbrowser DoS things with recursive iframes. But, you do not need to look at obscure content-types in order to mount effective DoS attacks. The two PoC mails nesty and multikill are very basic and simple and effective. Try them on your mail system! Every application needs to understand the multipart/mixed content-type, there is no way of refusing to parse it. Many applications in your system try to parse MIME: Spamfilters (at least old versions of spam assassin used to crash), antivirus, webmail servers, mailing list software (at least old versions of mailman used to crash), email clients, 3-letter-agencies (who knows?), msn-messenger (really!), mayhaps some IPS. Nesty and multikill were already recognized as a potential issue all the way back in 1996. Mike Weston worries about thousands of bodyparts, and Ned Freed thought that deep nesting was more likely to be an issue: http://www.imc.org/ietf-calendar/archive1/msg00487.html Thanks! That's quite an early reference and by one of the original authors of MIME. Cheers, Bruhns ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] DoS attacks on MIME-capable software via complex MIME emails
On Mon, Dec 8, 2008 at 2:56 PM, Bernhard Brehm [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] said: You want *real* loads of fun? Go read up on message/partial ;) snip The situation is quite similiar to the reason, why MTAs like sendmail are no real target for such attacks: No server should try to convert 8bit encoding to 7bit encoding any more. Nobody needs to split a message into several parts for transfer and expects the mailclient to reassemble the parts. Not all pieces of MIME-related software really need to understand these rather obscure content-types. Not exactly true. There might not be any clients which support it currently (don't know, myself) but *my* users are constantly trying to send huge messages that I don't allow for size reasons. Breaking them apart into chunks automatically for automatic reassembly by the recipient would very much appeal to them. Kurt ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] DoS attacks on MIME-capable software via complex MIME emails
== 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 7 parts. For a lot of software, about 2^16 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 2^16 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
Re: [Full-disclosure] DoS attacks on MIME-capable software via complex MIME emails
On Mon, 08 Dec 2008 19:12:26 +0100, Bernhard Brehm said: 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. You want *real* loads of fun? Go read up on message/partial ;) Nesty and multikill were already recognized as a potential issue all the way back in 1996. Mike Weston worries about thousands of bodyparts, and Ned Freed thought that deep nesting was more likely to be an issue: http://www.imc.org/ietf-calendar/archive1/msg00487.html * To: Mike Weston [EMAIL PROTECTED] * Subject: Re: More on merged drafts. * From: Ned Freed [EMAIL PROTECTED] * Date: Fri, 06 Dec 1996 14:01:39 -0800 (PST) * Cc: Alec Dun [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] * In-reply-to: Your message dated Fri, 06 Dec 1996 10:58:29 -0800 * References: * Sender: [EMAIL PROTECTED] Alec Dun wrote: I believe MIME is the right way to encapsulate objects following reasons: 1. MIME already has a way to represent multiple objects in a message. My guess would be that if many MIME parsers were presented with a multipart MIME message with thousands of parts (like someone's entire schedule for a few months), they would blow up. This is just orders of magnitude more complex than this mechanism is typically called upon to handle today. Maybe I'm just overly proud of my own implementation, but I don't think that most implementations will have a problem handling this sort of thing. I routinely receive MIME messages with anywhere from several dozen to several hundred attachments and have no real problem with it. Nesting is very different matter, BTW. I can readily believe that many implementations won't handle MIME structure nesting a thousand levels deep. (I also have experience in this area to back up this assessment.) But the usage being proposed here isn't a deeply nested structure, at least not as far as I can tell. pgpNqwEJDC44N.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
