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

[David F. Skoll]

On Fri, 24 Sep 2004, advisories wrote:

> > In this case, you canonicalize by picking just one of the fields.
> > As long as you pick something unambiguous, you will be OK.

> However this is not possible; as I have stated, there *is* ambiguity.

No. It is possible to write out a MIME message which cannot be interpreted
ambiguously by software that correctly obeys the relevant RFCs.

> There is not one canonical version.

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.

> > No. You didn't read correctly: You *always* re-formulate the
> > MIME to canonicalize the message. You *never* pass anything on unimpeded.

> I did read it correctly, and I do understand. The logic is quite simple; the
> receiving agent must not detect anything that the security product does not.
> If your security product does not recognise that the content is dangerous,
> then it really doesn't matter whether it reformats it or not.

It does. That's a critical point that you are missing.

> If the reformatting does not damage the attack vector, then it will
> still succeed.

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.

> > It is more difficult to attempt to detect malformed MIME than it
> > is to simply canonicalize *everything*,

> I agree, but simple solutions to complex problems often turn out to be
> wrong. In all the empirical testing we did, we did not once detect a
> standard mail agent that generated a mailbody with certain categories of
> malformed MIME. However, almost all without exception would still receive
> the same malformed mailbody. Rather than trying to reformat the mailbody and
> deliver a friendly version, the safe solution is to detect it and discard it
> at this point.

But you're not making sense. You contend that *any* MIME message is
ambiguous. So a C routine to detect an ambiguous MIME message would
look like this:

int
message_is_ambiguous(MIME_Message *m)
{
return 1;
}

Certainly safe; hardly helpful.

--
David.

[David F. Skoll]

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.

[David Wilson]

> 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@isode.com>
Isode Limited