bugtraq - Re:[3] 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-next>] [day] [month] [year] [list]

Message-ID: <002d01c4a250$a9356a30$d4f0bb51@vegetabl3.org>
Date: Fri, 24 Sep 2004 17:07:57 +0100
From: "advisories" <advisories@...saire.com>
To: <bugtraq@...urityfocus.com>
Subject: Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue

# This has been re-sent several times in the last week, but for whatever
reason, my email hasn't been getting to the bugtraq list.

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

However this is not possible; as I have stated, there *is* ambiguity. There
is not one canonical version. The receiving agents *do* interpret this
ambiguity in different ways; for you to make a choice at this point will be
arbitrary.

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

As before; there is ambiguity. If your product is not aware of this, then it
has failed. Additionally, in this particular situation, friendly is a
secondary concern to safe. If you really must be friendly, send an alert
informing the user that their email has been discarded. ;)

> No.  You didn't read correctly:  You *always* re-formulate the
> MIME to canonicalize the message.  You *never* pass anything on unimpeded.

I did read it correctly, and I do understand. The logic is quite simple; the
receiving agent must not detect anything that the security product does not.
If your security product does not recognise that the content is dangerous,
then it really doesn't matter whether it reformats it or not. If the
reformatting does not damage the attack vector, then it will still succeed.
As I have established above, there is no single canonical mailbody; the fact
that this situation exists at all is enough to show that the canonical model
is flawed.

> It is more difficult to attempt to detect malformed MIME than it
> is to simply canonicalize *everything*,

I agree, but simple solutions to complex problems often turn out to be
wrong. In all the empirical testing we did, we did not once detect a
standard mail agent that generated a mailbody with certain categories of
malformed MIME. However, almost all without exception would still receive
the same malformed mailbody. Rather than trying to reformat the mailbody and
deliver a friendly version, the safe solution is to detect it and discard it
at this point.

> MIMEDefang is GPL'd; I do not benefit financially from plugging it.

Marketing is marketing; it is either good or it is bad. However hypocrisy is
unambiguous.

If you genuinely want to contribute, contact NISCC, request a set of the
test tools, and then publish your results.

Regards,
Martin O'Neal