Re: Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding

[David Covin]

On Tue, 14 Sep 2004, David F. Skoll wrote:

> On Tue, 14 Sep 2004, advisories wrote:
>
> > - It identifies the MIME message as malformed and blocks it.
> > - It fails to interpret the MIME field (or message).
>
> > The first of the two would be the correct behaviour for a security
> > conscious product,
>
> I disagree. There is one, and only one, way for gateway security
> products to securely handle MIME messages:
>
> Build a data structure representing the MIME message, and then throw
> away the original message, re-generating a *valid*, well-formed MIME
> message from the data structure.
>
> This method alone guarantees[1] that the security product has exactly
> the same interpretation of the message as any other software that
> subsequently receives it. It also has the benefit of providing a
> "reasonable" interpretation for common MIME errors---blocking all mail
> that deviates even the slightest from the official MIME specifications
> would result in a significant fraction of all e-mail being blocked.

Two points:

1. A quibble. As you implicitly note, both canonicalizing MIME messages
and dropping malformed ones are secure approaches. Dropping all
incoming messages would also be a secure approach. It's fair to argue
that canonicalizing is the more useful policy, but not that it is the
only secure one.

2. Your logic sounds convincing, but interposing a proxy that
systematically changes incoming messages raises red flags in my mind.
Naive obscenity filters have created all sorts of problems doing this sort
of thing. Yours is a more sophisticated approach, but I still see the
potential for strange interactions between the gateway security product's
MIME implementation and those of sending and receiving programs. Have you
found this to be a problem, for those who've been using this filter?

-----------------------------------------------------------------
David Covin dcovin@nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street Charlestown, MA 02129 USA

[David F. Skoll]

On Tue, 14 Sep 2004, advisories wrote:

> - It identifies the MIME message as malformed and blocks it.
> - It fails to interpret the MIME field (or message).

> The first of the two would be the correct behaviour for a security
> conscious product,

I disagree. There is one, and only one, way for gateway security
products to securely handle MIME messages:

Build a data structure representing the MIME message, and then throw
away the original message, re-generating a *valid*, well-formed MIME
message from the data structure.

This method alone guarantees[1] that the security product has exactly
the same interpretation of the message as any other software that
subsequently receives it. It also has the benefit of providing a
"reasonable" interpretation for common MIME errors---blocking all mail
that deviates even the slightest from the official MIME specifications
would result in a significant fraction of all e-mail being blocked.

> To be effective tools, the security products must not only be able to
> process encoding techniques implemented as per the relevant standard,
> but also common misinterpretations and deliberate corruptions.

I disagree. There are an infinite number of ways to malform MIME
messages, and some of them have "reasonable" interpretations. Trying
to anticipate all possible interpretations of a malformed MIME message
and to divine which interpretations might be dangerous is a mug's game,
akin to trying to fight viruses with virus signatures.

Just as the one and only fix to prevent e-mail viruses is to avoid
software that can possibly interpret e-mail messages as executable,
the one and only fix to prevent problems from malformed MIME is to
canonicalize the MIME at the gateway.

Anyway, as a vendor (of MIMEDefang: http://www.mimedefang.org/), my official
statement is as follows:

Out of the box, MIMEDefang does not canonicalize MIME messages,
and hence may allow malformed MIME messages through that
it interprets differently from mail clients.

The sample filter shipped with MIMEDefang contains the following
text; we leave it up to our users to decide if they want
the additional protection:

# Some viruses produce malformed MIME messages that are misinterpreted
# by mail clients. They also might slip under the radar of MIMEDefang.
# If you are worried about this, you should canonicalize all
# e-mail by uncommenting the action_rebuild() line. This will
# force _all_ messages to be reconstructed as valid MIME. It will
# increase the load on your server, and might break messages produced
# by marginal software. Your call.

This text has been in our product since March 1, 2004, and the facility
to canonicalize MIME messages has been around since February 17, 2002.

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

Regards,

David

[1] The guarantee holds, of course, for software that correctly interprets
well-formed MIME. All bets are off for client software that can misinterpret
correct MIME messages.

[David F. Skoll]

On Wed, 15 Sep 2004, David Covin wrote:

> Two points:

> It's fair to argue
> that canonicalizing is the more useful policy, but not that it is the
> only secure one.

Fair enough, with the caveat that it's probably easier to canonicalize
than to detect all MIME messages that might possibly be misinterpreted.

> 2. Your logic sounds convincing, but interposing a proxy that
> systematically changes incoming messages raises red flags in my mind.

Indeed.

> Yours is a more sophisticated approach, but I still see the
> potential for strange interactions between the gateway security
> product's MIME implementation and those of sending and receiving
> programs. Have you found this to be a problem, for those who've
> been using this filter?

I have run into some problems, which is why the canonicalization is
disabled by default.

Regards,

David.