Date: Sat, 18 Sep 2004 11:37:35 -0400 (EDT)
From: "David F. Skoll" <dfs@...ringpenguin.com>
To: advisories <advisories@...saire.com>
Cc: bugtraq@...urityfocus.com
Subject: Re:[2] Corsaire Security Advisory - Multiple vendor MIME RFC2047
 encoding issue


On Fri, 17 Sep 2004, advisories wrote:

> > This method alone guarantees [for software that correctly
> > interprets well-formed MIME] that the security product
> > has exactly the same interpretation of the message as any
> > other software that subsequently receives it.

> There are a number of logical flaws in your reply, but lets focus on the
> statement above (I've added the caveat inline for brevity):

> Firstly, this statement presupposes that there is a single (or at least
> consensus) way of defining what well-formed MIME is. This just isn't so.
> There is, for example, no clear guidance on what an agent should do when it
> receives duplicate fields. RFC822 states "This specification permits
> multiple occurrences of most fields. Except as noted, their interpretation
> is not specified here, and their use is discouraged".

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

> If
> however, you choose to interpret the mailbody (as you have suggested) then
> at some point you must select one of the possible interpretations to deliver
> to the ultimate recipient (or you choose to deliver them all, passing on the
> attack unhindered). The point being that whatever you now choose is
> arbitrary, and will not be the same as a significant percentage of the
> receiving agents.

Delivering something unambiguous is as safe as not delivering anything,
and arguably friendlier.

> Secondly, logic being what it is, the inverse of your statement is also
> true; the model you have described doesn't only rely on the receiving agent
> correctly interpreting well-formed MIME, it depends on in *not* interpreting
> anything that the security product also does *not*. As a simple example, if
> your security product's interpreter identifies the source mailbody as
> plain-text and simply places this into your destination mailbody, then it
> will have passed on the malformed body unimpeded.

No.  You didn't read correctly:  You *always* re-formulate the MIME
to canonicalize the message.  You *never* pass anything on unimpeded.
As long as your canonicalization is correct, you're OK.

> Thirdly, the statement assumes that the algorithm that you use to interpret
> the source mailbody is itself not subject to any flaws. Developing perfect
> code is a non-trivial task (as a quick browse through the MIMEDefang
> changelog will show).

It is more difficult to attempt to detect malformed MIME than it is
to simply canonicalize *everything*, as a quick browse through just about
any code will show.  Writing code to generate unambiguous MIME messages is
an order of magnitude simpler than writing code to try to parse MIME
messages and determine if they're ambiguous.

> > [The rest of the advisory read like a press release or
> > marketing paper, so it is deleted.]

> Granted, although I suspect that the irony of you plugging your own product
> throughout your reply is lost on you.

MIMEDefang is GPL'd; I do not benefit financially from plugging it.  Besides,
you seemed to be soliciting responses from vendors; I gave mine.

--
David.

Powered by blists - more mailing lists