> Am 02.07.2018 um 03:33 schrieb martijn.list <martijn.l...@gmail.com>: > > On 02-07-18 01:15, Dr. Rolf Jansen wrote: >> Hello, >> >> I read carefully the technical paper about the exfiltration attack >> (efail) on decrypted S/MIME or PGP content. >> >> https://efail.de >> https://efail.de/efail-attack-paper.pdf >> >> According to my understanding, sanitizing text/html content to a certain >> extend in the mail body should mitigate the attack. Since the e-mail >> sender may send an encrypted message to a number of receivers at the >> same time, who are not necessarily all behind our Postfix server, the >> mitigation would be partial from the senders point of view, but should >> be complete on the receivers site getting sanitized HTML content only. >> >> I am planning to write an after-queue content filter. Full HTML >> sanitizing is out of the scope in the moment, however, inserting the >> four character sequence '>"> (in words: single-quote, greater, >> double-quote, greater) right at the end of a text/html multipart, which >> is directly followed by an application/pkcs7-mime part should be >> sufficient to close the ef-attack vector. BASE64 transfer encoded HTML >> needs to be decoded before, of course. >> >> Does this sound reasonable? > > I'm not certain that inserting '>"> will help. If you can insert > arbitrary characters, the attacker might also be able to "escape" you > escape sequence.
Perhaps a misunderstanding, I want to apply the filter to incoming mails only, after having arrived in the safe harbor, right before local mail delivery. Here the only MitM who could manipulate the mails would be myself, of course. If a theoretical hacker would come this far, then we would have other, way more serious concerns than EFail. Also '>"> is not exactly an escape sequence but the closing sequence of HTML tag attributes, and among these of any kind of external links. '> closes the flavour where the attribute values are quoted by single quotes and "> close the flavor where the attribute are quoted by double quotes. Yet there is a point in your objection, in that an attacker could do some quoting magic with interleaved single and double quotes which would prevent the '>"> sequence to close his tag. I need to investigate this, perhaps an 8 char sequence might close anything which is left open, either of '>">'>"> or '>">">'> -- in need to do some experiments. All this is about the direct exfiltration attack, i.e. leaving the encrypted content untouched, only embracing it with tailored HTML tags/attributes. As said already, I read the technical paper carefully, and I do not believe too much in the viability of the Generic Malleability Gadgets. This might work in some specially selected cases, but anyway here is nothing which I (left alone with my skills) could do about. Yet, the wide open security flaw is the direct exfiltration, since this is so easy to explore and any script kid could do it. I still think that the right thing to do is to close this easy real world flaw first, before closing the theoretical holes. > I did some analysis of EFAIL for S/MIME. The option we implemented was > to add some detection for EFAIL and possible refuse to decrypt if EFAIL > was detected. See for more info: > > https://www.ciphermail.com/blog/efail-detection-and-prevention.html > >> Did somebody wrote this kind of a filter already and would be ready to >> share it with others? > > You might try CipherMail (https://www.ciphermail.com/gateway.html) Ah, this is interesting - combining the mitigation against the direct attack vector (S/MIME part untouched) with the detection whether the encrypted data has been tampered with, and in case move it into quarantine. I will have a closer look into this. >> If not, I will start the work in the course of this week. Any comments, >> are welcome. >> >> Once the filter is working, I would only need to ask my peers not to Cc, >> Bcc, and/or mail-To encrypted messages to other parties at the same >> time, at least until most of the e-mail clients sanitize HTML mails >> internally - which may take a while, though. > > We spend quite some time trying to attack mail clients with the EFAIL > S/MIME attack. Even though inserting data into the stream is easy, we > haven't been able to actually misuse Outlook. Outlook is a picky email > client and refuses to decrypt email if not all things are exactly > correct. Allowing characters to be inserted into an encrypted stream is > a serious issue. However I think that in practical cases, attacking > S/MIME on Outlook is not easy (or not possible at all). This part of the gadget attack in the technical paper looks quite theoretical to me, and therefore, I am not surprised that it does not work in a real world setup. Anyway I do not believe that an averagely skilled C programmer like me, can do much about this - fiddling inside of encrypted blocks in order to repair it, that's not me who can do that. On the other hand, insertion of something like '>"> into a non-encrypted stream of bytes at a defined place, I can do in no time. Detection of incorrect bytes in a stream is even more easy to do. So, thank you very much for your valuable thoughts and information. I have more reading to do, and perhaps I will start coding soon. Best regards Rolf
