bugtraq - Re: Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44.0409151128320.25894-100000@macau.nmr.mgh.harvard.edu>
Date: Wed, 15 Sep 2004 11:41:58 -0400 (EDT)
From: David Covin <dcovin@....mgh.harvard.edu>
To: "David F. Skoll" <dfs@...ringpenguin.com>
Cc: advisories <advisories@...saire.com>, <bugtraq@...urityfocus.com>
Subject: Re: Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding
 issue

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@....mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street        Charlestown, MA 02129     USA