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.58.0409142200250.7341@shishi.roaringpenguin.com>
Date: Tue, 14 Sep 2004 22:15:58 -0400 (EDT)
From: "David F. Skoll" <dfs@...ringpenguin.com>
To: advisories <advisories@...saire.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding
 issue

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.