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-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 26 Sep 2004 12:43:16 -0400 (EDT)
From: "David F. Skoll" <dfs@...ringpenguin.com>
To: advisories <advisories@...saire.com>
Cc: bugtraq@...urityfocus.com
Subject: Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047
 encoding issue

On Fri, 24 Sep 2004, advisories wrote:

> > 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.

No.  It is possible to write out a MIME message which cannot be interpreted
ambiguously by software that correctly obeys the relevant RFCs.

> There is not one canonical version.

No, but you can make a version that is impossible to misinterpret
except by terminally buggy software.  Besids, if any possible MIME
message can be ambiguous, as you imply, then the only safe action is
to discard every single MIME message, period.

> > 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.

It does.  That's a critical point that you are missing.

> If the reformatting does not damage the attack vector, then it will
> still succeed.

The reformatting *must* eliminate the attack vector, because it *must*
force correctly-written software to interpret the message the same way
as the security agent.  As I wrote before, if you contend that this is
impossible, then any MIME message at all is unsafe and must be discarded.

> > 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.

But you're not making sense.  You contend that *any* MIME message is
ambiguous.  So a C routine to detect an ambiguous MIME message would
look like this:

int
message_is_ambiguous(MIME_Message *m)
{
	return 1;
}

Certainly safe; hardly helpful.

--
David.