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

Date: Wed, 29 Sep 2004 09:24:35 +0100
From: "advisories" <advisories@...saire.com>
To: <bugtraq@...urityfocus.com>
Subject: Re:[4] Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue

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

You have simply changed the subject; this is quite different from your
previous statement that it is possible to create a single canonical version
by selecting a field from multiple choices.

> If any possible MIME message can be ambiguous, as you imply,
> then the only safe action is to discard every single MIME
> message, period.

*May* be ambiguous, not *must* be ambiguous. The safe action is to detect
and discard the ambiguous ones.

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

It does no such thing. The security product has no control over the client
at all, so cannot force it to do anything. This model can only work if the
client interprets the mailbody in the same way as the security agent, and
more importantly does *not* interpret anything else.

In the real world, this simply isn't the case.

Regards,
Martin O'Neal