[Tickets #12062] Re: Mime parser fails to parse multipart message

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12062
------------------------------------------------------------------------------
  Ticket             | 12062
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Mime parser fails to parse multipart message
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2013-02-23 22:31) wrote:

> The initial Kolab parse code uses getStructure() which in turn uses  
> Horde_Imap_Client::FETCH_STRUCTURE. At least the cyrus imap server  
> sends back the full structure and is unimpressed by the missing  
> MIME-Version header.
>
> Peeking through the cyrus code, it just checks for "multipart" in  
> the Content-Type header.
>
> I've also looked at the dovecot code. It checks for the presence of  
> the "Content-Type" header field if it doesn't find "MIME-Version".  
> This behavior can be disabled by a flag but it is enabled by default  
> (and there's no code to configure it by the user)
> See also here:
> http://www.dovecot.org/list/dovecot/2009-November/044311.html
> "...but there were enough broken mails that I decided to make this  
> optional in code (but
> not by admin)"

I rarely disagree with Timo, but I do here.  This is a bad idea.

But whatever Cyrus and *certain* versions of Dovecot do is irrelevant.  
  The issue still remains that a large number of IMAP servers  
**won't** parse these messages.  By Timo's own numbers, this is at  
LEAST 40% of the servers out there (just counting the number of  
Courier installs and a reasonable estimate of the number of servers  
running the old dovecot software: http://www.openemailsurvey.org/)

> What could go wrong if we do the same (to be more relaxed on parsing)?

1. I know for a fact (because I have dealt with them personally) that  
certain SPAM/Antivirus tools WON'T parse a message missing the  
MIME-Version header as a MIME message.  So it becomes absolutely  
trivial to bypass security checks on these machines by doing something  
like this:

Content-Type: multipart/mixed; bounday=foo

--foo
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

[Malicious base64 data here]
--foo--

Your solution ignores this reality.  Not to mention you can't check  
for Content-Type as a substitute for MIME-Version since Content-Type  
is not guaranteed to exist.

There is only 1 required field for a MIME message.

2. The idea of "be liberal in what you accept" that is always thrown  
around by the other side in this argument is crap.  That is NOT what  
the goal should be.  Instead, it should be "be liberal in what you  
accept BUT ONLY IF it doesn't break other things and/or open security  
holes."

It is one thing to accept, for example, extra whitespace sent back  
from an IMAP server even though this is specifically prohibited in the  
RFC.  That is because this extra whitespace isn't going to change or  
affect anything.

It is a *totally* different thing to completely ignore the MIME spec  
and transform a text/plain message into a message that potentially  
carries malicious data.  There is only ONE mandatory field

3. Where do you draw the line on trying to work around admittedly  
broken senders?  For example, what about an MUA that sends the  
following message:

MIME-Version: 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding : base64

[Malicious base64 encoded data]

An RFC compliant MIME parser will correctly parse this as jumbled text  
because the data is 7bit encoded.  Conversely, any MUA that is trying  
to be liberal in what they parse by instead assuming that this message  
contains base64 data is Doing It Wrong (TM).  This is not a base64  
encoded message.

Broken clients are broken clients.  These broken clients send out  
broken messages.  It should not (and must not) be our duty to try to  
"fix" these broken messages.

And quite frankly, 99.9% of all broken MIME messages are being sent  
out by spammers anyway.  We should not sacrifice security to try to  
handle the tiny percentage of broken mailers that exist.