Hi Albrecht, (comments below, sorry for the nasty way that Outlook formats inline replies)
On 10/15/17, 10:02 AM, "Albrecht Dreß" <[email protected]> wrote: Hi Jeff: Am 14.10.17 22:10 schrieb(en) Jeffrey Stedfast: > This is all interesting. Does the slide talk about the pros and cons of each behavior or suggest what might be the best way to handle each case? Maybe I should add a little background about this presentation… The author works for a German company which among other things produces security gateways (genua <https://www.genua.de/en.html>; competitors are e.g. Fireeye, Palo Alto Networks, Cisco, …; no, I *don't* work for any of them!). These devices are able to decode traffic, in particular http, https and emails, and to scan the decoded content for “usual” malware as well as for advanced persistent threats (APTs). The problem: if (in the case of emails) the security appliance and the final MUA interpret creatively crafted half-broken MIME structures /differently/, the attack may pass the gateway unrecognised and thus reach the target. And as MUA's also tend to interpret these messages differently, the attack message may look benign on, say, iOS, whereas it will successfully infect a machine running Outlook on Windows (the usual target). As to mitigate the attack, some of the gateways re-write emails to a sane RFC-compliant format, so the final MUA will see *exactly* the content which has been inspected by the gateway (however, this approach /may/ also break cryptographic signatures; think of the RFC 2633 and 3156 requirements). Ah, yes, okay – now I understand better. Different software interprets things differently so when writing software that attempts to filter out viruses and other types of attacks, it might not interpret things exactly the same as the user’s email client. Therefore, I think it is not possible to define a “correct” behaviour for the cases presented in the talk, with the exception that odd but standard-compliant content should of course be interpreted correctly. Afaict, GMime handles unexpected but legal line folding (slide 21) properly. I did not test the case of unnecessarily RFC 2231 encoded header tokens (example on slide 22). The NUL byte inserted by GMime when decoding base64 content with “=” inside the block (slide 32) looks like a bug to me, though. It might be, I’ll have to look into it a bit more. So, instead of guessing what the sender (or attacker…) did actually want to transmit, IMO the proper approach is to detect these cases and to treat the messages as possibly dangerous. This applies to both a MUA as well as to some kind of “security checker” (think of a milter). Thus, it would be crucial to get detailed information if the parser detected something odd in the message. The severity would of course be very different. E.g. unencoded 8-bit characters in message headers are a common problem of some web mailers (Balsa already displays a notice, and the Milter would just accept them). But the other examples presented (maybe with the exception of the line folding on slide 21) should raise a *BIG* warning in the MUA that the message may be an attack (a milter/gateway should probably shift it into quarantine). This leads to the question if it would be possible to extract this information from the GMime parser. Although Balsa is probably not a target (due to the regrettably small number of installations and the robustness of Linux), it should be able to display a warning as mentioned above, just in case the user reads the messages using different MUA's (think of IMAP, plus Outlook/iOS/Android/…). But it would be an *extremely* helpful feature for writing some kind of “security scanner”. I think it would be possible, I think the question is mostly how to surface this information in a usable way. Jeff _______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
