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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0409271630420.26275@shishi.roaringpenguin.com>
Date: Mon, 27 Sep 2004 16:42:07 -0400 (EDT)
From: "David F. Skoll" <dfs@...ringpenguin.com>
To: David Wilson <David.Wilson@...de.com>
Cc: advisories <advisories@...saire.com>, bugtraq@...urityfocus.com
Subject: Re: Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047
         encoding issue

On Mon, 27 Sep 2004, David Wilson wrote:

> A core problem in this area is that there is much software "out there"
> which DOES NOT interpret MIME messages according to the standards.

Such software is *impossible* to protect with a gateway device unless said
gateway device discards all MIME messages.  At some point, the words
"Defense In Depth" should come to mind.

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

If canonicalization includes dropping comments, it might have.

> The second example I would pick is how Microsoft UAs fail to heed the
> Content-type: text/plain field.

"Defense in Depth".  Any security consultant who does not recommend to
his clients that they stop using such broken software is cheating them.
Now, canonicalization can help if it renames attachments according to the
MIME type using certain rules (eg, any text/plain attachment gets renamed
*.txt.  That probably still won't stop all broken UA's.  Defense in Depth.

> 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):

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

No.  A canonicalizer doesn't have to preserve dangerous behaviour; it
can canonicalize the MIME by "seeing" the .exe and then taking action.
Alternatively, the canonicalizer's security policy might dictate that
attachments whose filenames match =?.*?= should be dropped.  I guess
what I'm saying is that canonicalization should always be used in
addition to any other detection techniques.

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

That's true, but as I wrote earlier, the only surefire way to prevent
misinterpretation of valid MIME is to block all MIME.  I think that
canonicalizing the message, where you canonicalize to a very limited
and strictly-controled use of MIME, is safe in the real world.  Trying
to enumerate every possible "dangerous" MIME-encoding technique is like
trying to enumerate all possible virus signatures:  Rewarding monetarily
for security companies, which providing little actual security to their
customers.

Regards,

David.