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.
