5 ms·
I'm not sure about "incredible expertise", but to illustrate with some - rather basic - points that I've seen people miss: - mailbombs exist - you can generate
by JoachimSchipper 11y ago
I'm not sure about "incredible expertise", but to illustrate with some - rather basic - points that I've seen people miss:
- mailbombs exist
- you can generate input that takes a lot of memory and/or CPU to process for almost any real-world parser - DoS is usually trivial (and compromise is within reach of advanced adversaries)
- you really want to limit the depth to which you parse MIME, doubly so if the parser is recursive
- decoding headers is really hard even if you just decode everything to UTF-8
- just because something claims to be text/plain doesn't mean that it's actually 7-bit, actually the character set it claims to be, doesn't contain any "interesting" Unicode characters, etc etc etc.
- receivers can and do MIME-sniff
- UTF-8 is actually pretty damn scary (rendering an arbitrary bytestring as UTF-8... should be safe, but there is at least one Linux graphics toolkit that will just not show the textfield if you include any application-specific characters, and rendering combined characters has had bugs in the past)
- ...
I assume you're familiar with the above; I just mean to point out that securely handling e-mail is hard.
- nickpsecurity 11y agoI have a way with bumbling choice of words haha. How about "plenty of expertise" instead? I was familiar with some of that but not others. Thanks for the list both for the extra details I learned and so people new to this will see some of the gotchas. Curious, has anyone put together a comprehensive treatment of most of the issues and solutions that you know of? Standard Mail Guard [1] and GEMSOS [2] (esp crypto seals) informed my approach. I just applied what I could of that (minus MLS) to build a proxy that just wrapped them up and sent them through a guard. Still had to deal with headers, transport was way easier, and left most to the client. The best example I know in commercial space that does it similarly (probably better) is Nexor [3]. Especially with Sentinel. Such architectures let designers make many tradeoffs in security vs performance vs compatibility. Simplistic example: security stuff in dedicate process might let me use safer language, better verification tools, MAC policy, compiler obfuscations, etc. Wouldn't be as easy if operating within the client's privileges or language. [1] https://cryptosmith.files.wordpress.com/2014/10/mailguard.pdf https://cryptosmith.files.wordpress.com/2014/10/mailguard.pd... [2] http://aesec.com/ http://aesec.com/ [3] https://www.nexor.com/sixa-technology https://www.nexor.com/sixa-technology (Note: I don't endorse it's assurance/code so much as architecture and strategy. EAL4+ is not high assurance lol. It's probably not cheap, either.)
- JoachimSchipper 11y agoI'm not aware of any comprehensive list, although I must admit that I haven't looked very closely. I am somewhat familiar with the concept of a mail guard, yes. ;-)
- nickpsecurity 11y agoOh shit: you work at Fox. You might be familiar with a few worthwhile concepts haha. Always good to run into others in the high-security field as there's so few these days. I did contract work that built into other's stuff but now days mostly do high-security R&D, recommendations, and evangelism. I give Fox a mention here and there on forums because they seem to know what they're doing with talented people. Hard to be sure with black boxes but seeing physical separation and a trusted path on RedFox was a good sign. Esp given most security devices don't have it. ;) Btw, is the trusted path the UART or done on GPIO's? Note: I keep my designs and essays on Schneier's blog, etc just to get them out there in hopes of public benefit. I'll send you some of them if you want so long as I get credit for that part of whatever you or Fox does with them. Usually all I ask for although paid consulting is a bonus I don't turn down. ;)
- JoachimSchipper 11y agoI couldn't possibly comment on the RedFox - pretty much everything that's not on the website is classified or at least need-to-know, and I haven't kept very careful track of what's on the web. I've looked at your work before, but I'd be happy to receive some more. Two points, though: (a) I'm incredibly busy right now, so don't expect a prompt response, and (b) we don't talk a lot about what we do, so don't expect to see a lot of credits in (open) print. (My apologies for both!)