[dev] Fwd: [Full-disclosure] DoS attacks on MIME-capable software via complex MIME emails

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Where does our own MIME parser stand in this regard? There are also
> follow-ups on FD and Bugtraq.

[snip]

> 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.

To begin, I will note that we do not normally do MIME parsing in IMP -  
the MIME parsing is done for us via the IMAP server (BODYSTRUCTURE  
command)  so any denial of service would occur there.

It is possible that with things like PGP, S/MIME, (the obscure)  
message/partial type, that we have to parse MIME data via the PEAR  
mimeDecode library.  So #1 - we don't control the code doing the  
parsing (this would be a PEAR issue rather than a Horde issues) and #2  
- PHP will run out of memory and terminate if too many MIME parts  
exist.  I think the latter is sufficient handling of this issue.

Although, mimeDecode *doesn't* correctly parse for the MIME-Version  
header so that's probably a bug in the software.

> == 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.

[see above]

> == 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 at hell>
> To: <foo at 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 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.

This report seems awfully misleading to me.  By his definition,  
multipart/appledouble messages are a potential DoS attack (since they  
are horrificly resource intensive to parse).  Or my mom trying to send  
me 75 photos from the birthday party she took using her 10 megapixel  
camera.  The simple fact is that mail messages are *not* an efficient  
way of transmitting information.  You can either accept the (minimal)  
annoyance of running into one of these MIME messages every once in a  
while or else go back to the day when only text/plain is allowed.

Regardless, these messages will either be handled at the IMAP level,  
the MTA level (these sort of crazy messages are bound to be captured  
by any halfway decent spam filter), or, as mentioned above, the PHP  
resource limits.  In the latter case, we have already faced this issue  
and have been successful for years - granted, a PHP error screen is  
not the best error handling method for exceeding resources but there's  
not a whole heck we can do about that.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]