bugtraq - Re: Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 27 Sep 2004 20:40:24 +0100
From: David Wilson <David.Wilson@...de.com>
To: "David F. Skoll" <dfs@...ringpenguin.com>
Cc: advisories <advisories@...saire.com>, bugtraq@...urityfocus.com
Subject: Re: Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047
         encoding issue

> No, but you can make a version that is impossible to misinterpret
> except by terminally buggy software.  Besids, if any possible MIME
> message can be ambiguous, as you imply, then the only safe action is
> to discard every single MIME message, period.

[snip]

> The reformatting *must* eliminate the attack vector, because it *must*
> force correctly-written software to interpret the message the same way
> as the security agent.  As I wrote before, if you contend that this is
> impossible, then any MIME message at all is unsafe and must be discarded.

A core problem in this area is that there is much software "out there"
which DOES NOT interpret MIME messages according to the standards. The
problem faced by software checking messages for attack vectors is that
they should interpret the message not according to the standards but
according to the misinterpretation of the standards by various broken
software, or perhaps despite the standards.

The first example I might quote relates to a buffer overflow
vulnerability in Outlook Express, I think it was, a few years ago. An
overlong Date: field in the header caused a classic buffer overflow.
Now, I don't know the details, but it is possible that this could have
worked even if the Date: field were correct according to RFC 2822. For
instance, there could be a very long comment in the field.
Canonicalization would not help here.

The second example I would pick is how Microsoft UAs fail to heed the
Content-type: text/plain field. They look at the data, and make
assumptions about its contents. This is slightly different from the area
of MIME ambiguities, but is another illustration of the problem faced by
software whose aim is to check for potential security vulnerabilities.
Correct MIME software treats text/plain as that, and would not think of,
for instance, executing and HTML script found within.

The third example relates to one of the Corsaire items. RFC 2047 makes
it crystal clear that MIME encoded-words MUST NOT be used in MIME
parameters, (I quote):

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field, or in any structured
     field body except within a 'comment' or 'phrase'.

That does not stop software both generating such parameter values and
interpreting them. While the example of the style (which I have seen):

  Content-disposition: attachment; filename==?us-ascii?Q?virus.exe?=

is clearly syntactically wrong (unquoted tspecials in the value), there
is nothing "wrong" with this:

   Content-disposition: attachment; filename="=?us-ascii?Q?virus.exe?="

So this SHOULD be passed unchanged by a canonicalizer. But if the
security software does not see the filename extension .exe, and relies
on this for some test, and the UA DOES see .exe, then there is a
problem. 

So, making sure the MIME message is in a form with a unique
interpretation of the standards does not stop other software from
misinterpreting the result.

cheers

-- 
David Wilson <David.Wilson@...de.com>
Isode Limited