bugtraq - Re:[2] 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: <001b01c49cbd$a1256130$d4f0bb51@vegetabl3.org>
Date: Fri, 17 Sep 2004 14:52:51 +0100
From: "advisories" <advisories@...saire.com>
To: <bugtraq@...urityfocus.com>
Subject: Re:[2] Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue

> This method alone guarantees [for software that correctly
> interprets well-formed MIME] that the security product
> has exactly the same interpretation of the message as any
> other software that subsequently receives it.

There are a number of logical flaws in your reply, but lets focus on the
statement above (I've added the caveat inline for brevity):

Firstly, this statement presupposes that there is a single (or at least
consensus) way of defining what well-formed MIME is. This just isn't so.
There is, for example, no clear guidance on what an agent should do when it
receives duplicate fields. RFC822 states "This specification permits
multiple occurrences of most fields. Except as noted, their interpretation
is not specified here, and their use is discouraged".  Because there are
multiple fields, there are now multiple interpretations of the same
mailbody; you can not produce a single canonical version; you must make a
choice. If you choose to detect the multiple occurrences and discard the
mailbody at this point (as I have suggested) then the story ends here. If
however, you choose to interpret the mailbody (as you have suggested) then
at some point you must select one of the possible interpretations to deliver
to the ultimate recipient (or you choose to deliver them all, passing on the
attack unhindered). The point being that whatever you now choose is
arbitrary, and will not be the same as a significant percentage of the
receiving agents.

Secondly, logic being what it is, the inverse of your statement is also
true; the model you have described doesn't only rely on the receiving agent
correctly interpreting well-formed MIME, it depends on in *not* interpreting
anything that the security product also does *not*. As a simple example, if
your security product's interpreter identifies the source mailbody as
plain-text and simply places this into your destination mailbody, then it
will have passed on the malformed body unimpeded. If the receiving agent
interprets it as a valid MIME construct, your security product has failed.

Thirdly, the statement assumes that the algorithm that you use to interpret
the source mailbody is itself not subject to any flaws. Developing perfect
code is a non-trivial task (as a quick browse through the MIMEDefang
changelog will show). Although this, of course, applies to any security
product that you put in this place, it does somewhat undermine your specific
guarantee.

> [The rest of the advisory read like a press release or
> marketing paper, so it is deleted.]

Granted, although I suspect that the irony of you plugging your own product
throughout your reply is lost on you.

Regards,
Martin O'Neal