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
