Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue |
|---|---|
| Date: | Fri, 24 Sep 2004 17:07:57 +0100 |
# 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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Correction to latest Colsaire advisories, advisories |
|---|---|
| Next by Date: | RE: Diebold Global Election Management System (GEMS) Backdoor Account Allows Authenticated Users to Modify Votes, Jeremy Epstein |
| Previous by Thread: | RE: New whitepaper "The Phishing Guide", Dehner, Benjamin T. |
| Next by Thread: | Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue, David F. Skoll |
| Indexes: | [Date] [Thread] [Top] [All Lists] |