BugTraq
DoS attacks on MIME-capable software via complex MIME emails Dec 08 2008 10:52PM
bruhns recurity-labs com (2 replies)
== 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

[ reply ]
Re: DoS attacks on MIME-capable software via complex MIME emails Jan 27 2009 03:22PM
Dave English (dave english thus net)
Re: DoS attacks on MIME-capable software via complex MIME emails Dec 09 2008 04:53PM
Vladimir '3APA3A' Dubrovin (3APA3A SECURITY NNOV RU)


 

Privacy Statement
Copyright 2010, SecurityFocus