Efail.de: are astroid users affected?

[hugoroy]

https://efail.de/

Maybe, if the users chooses to show HTML emails by default?

[mxmehl]

Probably one also has to enable loading external images by default to be vulnerable. But I'm not sure about this as Thunderbird doesn't display external images by default either but seems to be affected.

[gauteh]

As far as I can understand at this point you should not be vulnerable as long as you don't activate the HTML part (with the "potentially sketchy" warning there) and don't allow remote images to be displayed.

The attack requires that the attacker can access the original e-mail, so it is obviously doesn't matter for unencrypted emails since they would be directly available anyway.

Further, it is not clear yet whether you are vulnerable or not: each HTML part is not just appended sequentially, but inside other HTML tags. We need to look into whether this might be exploited somehow through the example <img src=" procedure. The HTML is not validated before rendered (hence the "potentially sketchy" warning).

Showing HTML emails by default will make this worse. If remote content (like images) can be loaded.

[hugoroy]

Thanks for the explanation! Best, Hugo

[gauteh]

I'm looking at mailpile.is analysis, if we look at the five points:

1. Mailpile does not display HTML content by default
2. Before displaying HTML, Mailpile cleans up malformed and incomplete tags.
3. When displaying HTML, Mailpile does not load remote content by default.
4. Mailpile respects the GnuPG error messages which warn of invalid data.
5. Mailpile never sends auto-replies to incoming mail.

Astroid adheres to points 1, 3, 5, and should show a warning on 4 (though I haven't tested this). Fixing 2 is tricky and hard to know if is completely safe, and is one reason for 1 and 3.

[gauteh]

A couple of things we can do:

• Use https://github.com/htacg/tidy-html5 to sanitize HTML (aka 2).
• Use html-tidy to remove any remote assets except images (won't really fix this issue, but will make things safer in other respects). Note that these are not loaded unless remote image loading is allowed, and still the page would have to be reloaded.
• Not display GPG HTML parts if decryption results in integrity error (aka 4).
• Allow to turn off GPG

[c-alpha]

<opinion>Kind of sad how people, who dub themselves as researchers/scientists, apparently couldn't resist the temptation of encouraging "generous interpretations" of their results for the sake of seeing their names in the news.</opinion>

But back to business...

Independent of any fixes, I think it would be useful to add astroid to the list of mail clients for VU#122919, which is the report underlying (and referenced by) both "scoop CVEs".

Actually, two vulnerabilities are described:

1. The "CBC/CFB Gadget Attack" is an attempt to circumvent the encryption and packaging itself. It is not new, and has never been considered a severe risk. In order to work, it requires access to either the victim's secret key, or sufficient quantities of plaintext (which in practice amounts to the same). IMO, we can ignore this, since neither can we solve it, nor is it a promising scenario for an attacker.

2. The "Direct Exfiltration" attack needs three convenience features in mail clients to be successful: hiding of the multipart structure, caching of the passphrase, and proactive fetching of remote content, including JS execution. Only if both convenience features are in place, an attack can be successful. If there is no passphrase caching, the user could become skeptical if he had to enter his passphrase several times to decrypt a "can we meet at 9pm" three-liner. If the multipart structure were shown, the user could become skeptical if there are more message parts than expected. Finally, if there's no JS execution and no retrieval of remote content, the attack fails.

What could also help to make users skeptical, would be to display all recipients and key ids of an encrypted block when prompting for the passphrase. Since the "direct exfiltration" attack uses an encrypted email sent by the victim in the past as a hidden message part, the list of recipients for that may not match the recipients list of the forged email.

So what could we do for astroid?

• I personally don't see HMTL sanitization as a promising option. It could keep us in a false sense of safety. IMO it will not be possible for a software to distinguish between "good" and "bad" HTML. Since the HTML sanitization takes HTML as input, and produces HTML as output, which is then considered "safe", this could invite further attacks which exploit bugs in the sanitization code.
• Not loading remote assets, and not executing any scripts (JS or other) would seem a very good option to me. It is a straightforward feature, and implementations are hence very unlikely to have sufficient bugs to make an attack look promising. The "don't load remote content" switch is off by default (afair), so to that end, we should be fine. How easy it would be to add a 'never execute any scripts in HTML" switch, I wouldn't dare to predict.
• Listing any and all recipients when prompting for the decryption passphrase would allow for easy common sense sanity checks by users. Of course an attacker can put the same recipients in the message header as were used by the victim when encrypting his original message, but that would require the attacker to do two things: (a) to use a modified SMTP server which only sends to the victim, but not to other recipients, and (b) to employ more social engineering since the contents of the forged message will need to make sense to the victim in the light of the recipients list. Not that this would be impossible, but I think it raises the bar quite a bit for the attacker.
• displaying the entire message structure before any non-plaintext parts are rendered would also seem useful to enable users' common sense sanity checks. I know that astroid already does that for multipart/alternative, but I haven't tried it with more complex message structures, so can't really gauge how good we are in this respect.
  As a long time Mulberry user, I came to like the way it's done there. The first plaintext part is always displayed. If the message has more parts, a message parts toolbar is shown right above the text area, and its collapsed by default:
  
  When the user clicks on the disclosure triangle, the toolbar is expanded to show the message's structure:
  
  Again, an attacker can of course employ further camouflage tactics to make the message appear to have a flat structure, but to cause am HTML rendering engine to misbehave in favour of the attacker, but again this raises the bar for the attacker.

Overall, I very much concur with @gauteh's assessment that HTML sanitization would not seem a promising way forward.

Additionally, I would be of the opinion that some new UI features (see bullets above) could help end-user awareness.

[gauteh]

Good points.

Showing encryption keys would not completely fix the issue anyway since the keys could be set to 0x0 (see #313 and #497). The passphrase is also not astroid, but part of the gnupg / keyring configuration pinetry configuration.

I am leaning towards putting each sub-part in an iframe with very strict restrictions. This was the plan to do for HTML parts anyway, but we could just as well do it for all parts. As you say, sanitizing the HTML is error prone, but could perhaps still be used to aid in viewing poor HTML. Normally this should be shown without any borders so that it would look more or less like it does already.

Remote assets are by default not loaded.

While I think the message structure is nice to have, I don't see that it has a lot of use. I'd not be against adding some kind of alternative view here if someone wants to step up to the challenge. The tree-structure is already readily available in the Astroid code. For me it seems that it would perhaps clutter the reading experience, and have somewhat limited use.

[gauteh]

#503 adds a configuration option for optionally disabling GPG (default enabled). It is not yet confirmed that the attack works on Astroid, nor is it I think likely, but if you want to be completely sure disable GPG.

[c-alpha]

Showing encryption keys would not completely fix the issue anyway since the keys could be set to 0x0 (see #313 and #497).

I think I imagined displaying sth. along the lines of "I'm now going to decrypt a chunk, which is encrypted for email-address (key-id), email-address (key-id), ...". Since the attack uses an old email I have sent in the past, that would give me an opportunity to think, when a seemingly harmless message (e.g. invitation to a meeting) contains stuff addressed to unrelated people. Of course an attacker could craft a message content that could make sense given the recipients, but that would have two preconditions: (a) the attacker would need to get the email addresses from the public key ids in the chunk (not everybody uploads theirs to a keyserver), in order to be able to (b) figure out what my relationships with these recipients are today, and what type of message content could therefore make sense to me.

Doesn't prevent anything technically, but raises the bar quite a bit.

The passphrase is also not astroid, but part of the gnupg / keyring configuration pinetry configuration.

Yes, of course. But if I would get information like the message I outlined above in astroid, immediately before the pinentry dialogue appears, I would get a chance to click "cancel" in the pinentry dialogue if something doesn't look right.

I am leaning towards putting each sub-part in an iframe with very strict restrictions. This was the plan to do for HTML parts anyway, but we could just as well do it for all parts. As you say, sanitizing the HTML is error prone, but could perhaps still be used to aid in viewing poor HTML.

I think sanitizing HTML would even create a new area of potential vulnerabilities. Most of today's code that renders HTML should be assumed to be fairly well tried & tested. Using the WebView provided by the platform should hence be a pretty safe bet, IMO. Well, at least as safe as one can practically get.

The HTML sanitization code on the other hand, would be a new thing that processes the HTLM and reacts to it. It has been (and probably will remain) much less tested and scrutinised than typical WebViews etc. It would hence seem quite probable to me that the HMTL sanitiser will have bugs, and that maliciously crafted (or simply randomly erroneous) HTML could cause it to do unexpected things. yet another source of buffer overflows, causing privilege escalations, etc. In that light, I think that I would even be against having any HTML sanitization. If a mainstream WebView can't make it readable, how much more can any HTML sanitization salvage? Also, sanitizing HTML is DWIM (do what I mean), i.e. can have surprising results.

[...]
While I think the message structure is nice to have, I don't see that it has a lot of use. I'd not be against adding some kind of alternative view here if someone wants to step up to the challenge. The tree-structure is already readily available in the Astroid code. For me it seems that it would perhaps clutter the reading experience, and have somewhat limited use.

I don't think I was asking for an alternative view. maybe everything is already in place; I just hgaven't had the opportunity to test how astroid shows a complex MIME message.

My idea was to show the message's structure, so that the user could apply common sense if he wanted to. Example: I get an email which says "can we meet for coffee at 3?". In the first scenario, the attacker has not invested a lot of effort, and it contains a multipart/alternative part with plaintext and HTML versions of the meeting request, and a third part which is HTML, and 32kB in size. The extra part with unusual size would seem odd, and the user could decide to not open it.

If the attacker chooses to invest more effort, invisible HTML with my old encrypted message, could be embedded in an HTML-only message. In this case, showing the message structure would not help, of course.

Again doesn't prevent anything technically, but raises the bar.

[gauteh]

c-alpha writes on May 24, 2018 18:34:

Doesn't prevent anything technically, but raises the bar quite a bit.

See below.

> I am leaning towards putting each sub-part in an iframe with very strict restrictions. This was the plan to do for HTML parts anyway, but we could just as well do it for all parts. As you say, sanitizing the HTML is error prone, but could perhaps still be used to aid in viewing poor HTML. I think sanitizing HTML would even create a new area of potential vulnerabilities. Most of today's code that renders HTML should be assumed to be fairly well tried & tested. Using the WebView provided by the platform should hence be a pretty safe bet, IMO. Well, at least as safe as one can practically get.

Agreed. So a sub-iframe, sandboxed in the best possible way, should be the safest bet. We will never get around some HTML sanitization, e.g. GMime is used to escape all HTML tags in regular text/plain so before we put it into the WebView (for obvious reasons). If we were to use HTML sanitization we would rely on established libraries like html-tidy. I agree that it will be hard to completely prevent against this kind of attacks, but I have for a while been thinking about how to make the HTML parts have the same font-size / background color as the rest of astroid. Perhaps it would be better to just provide zoom / text-size keybindings for each sub-iframe. Well, now after having read your comments and thought some more about it I don't think it is worth trying to fix the HTML - just display it in a sandboxed iframe. Even better reason to finalize #455! (the webkit version we are currently using is full of holes, probably a much bigger issue for us than efail).

Again doesn't prevent anything technically, but raises the bar.

In my experience these kind of measures are really easy to miss. If you receive a lot of GPG encrypted e-mail you'd just skim past faster than the facebook terms-of-service. Unless we actually handle GPG error codes and warnings properly [0] and secure against the HTML attack (which I think really is a mail-client vulnerability or at least responsibility!) we will not be any safer. I absolutely agree that your suggestions would make it harder, but I think it would be better to provide this information in the GPG header that we currently have - perhaps with some attention-grabbing color? The responsibility of safety then lies on not allowing any information to be sent from the client. In short, the combination of the effort required to implement these suggestions compared to the actual security it provides makes them not worth it. Especially, if we can make ourselves safe by using iframes and not allowing loading remote-content. Indeed, we could even forbid loading remote-content if the message has encrypted parts unless a config option is turned on or something. [0] https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

[c-alpha]

On 2018-05-27, at 09:34 , Gaute Hope ***@***.***> wrote: [...] Agreed. So a sub-iframe, sandboxed in the best possible way, should be the safest bet.

Agreed.

We will never get around some HTML sanitization, e.g. GMime is used to escape all HTML tags in regular text/plain so before we put it into the WebView (for obvious reasons). If we were to use HTML sanitization we would rely on established libraries like html-tidy.

I see; agreed.

I agree that it will be hard to completely prevent against this kind of attacks, but I have for a while been thinking about how to make the HTML parts have the same font-size / background color as the rest of astroid.

Nah...

Perhaps it would be better to just provide zoom / text-size keybindings for each sub-iframe.

Yes!

Well, now after having read your comments and thought some more about it I don't think it is worth trying to fix the HTML - just display it in a sandboxed iframe. Even better reason to finalize #455! (the webkit version we are currently using is full of holes, probably a much bigger issue for us than efail). > Again doesn't prevent anything technically, but raises the bar. In my experience these kind of measures are really easy to miss. If you receive a lot of GPG encrypted e-mail you'd just skim past faster than the facebook terms-of-service.

:-) Agreed.

Unless we actually handle GPG error codes and warnings properly [0]

Fully agree. Good one; thx for the pointer. Was nodding to myself all the way reading it.

and secure against the HTML attack [...] we will not be any safer.

The million dollar question seems to be: how do we achieve reasonable resilience, without dumbing things down too much?

(which I think really is a mail-client vulnerability or at least responsibility!)

I think it is [1]. [1] https://www.condition-alpha.com/blog/?p=1538

I absolutely agree that your suggestions would make it harder, but I think it would be better to provide this information in the GPG header that we currently have - perhaps with some attention-grabbing color?

Fully agree.

The responsibility of safety then lies on not allowing any information to be sent from the client.

We'll probably still want to allow the accept/decline buttons in our calendar invites, and the "manage booking" buttons in our booking confirmation emails to work. Aiming for a sensible middle ground, I am fully with you on the sandboxed i-frame approach. Over and above what we have today (not loading any remote resources without expressed user intent), the i-frame environment should not be able execute any scripts (whether embedded in the message HTML or in downloaded resources), and should receive nothing but the contents of exactly one MIME part.

In short, the combination of the effort required to implement these suggestions compared to the actual security it provides makes them not worth it.

I see; agreed.

Especially, if we can make ourselves safe by using iframes and not allowing loading remote-content. Indeed, we could even forbid loading remote-content if the message has encrypted parts unless a config option is turned on or something. [...]

Based on how I myself turn on "expert mode" because I thought I knew what I was doing, but only to concede in hindsight that I actually wasn't, I does not seem very compelling to me to allow users turning off such restrictions. ;-)) What do you think about the "message slicing" I was hinting to above, i.e. to confine each MIME part in its own enclave, and apply any subsequent processing to data in that enclave only? The Efail attack vector takes advantage of a shortcut taken by mail client implementations, which is that they process things from two different layers (MIME boundaries and PGP boundaries) at the same time. The attack cunningly interleaves both types of boundaries, actually resulting in an illegal message structure. If the MIME boundaries are enforced before any higher layer boundaries are even considered, then the attack fails. And in astroid, we're already doing this (hence you get GPG errors when opening an Efail message). Having said that, I think we can even claim we're not vulnerable to Efail. Even if the script in the HTML were executed, the decryption would have failed, and the script would only upload the cyphertext. If an attacker wanted to circumvent that, he would need to produce a legal MIME structure. E.g. something similar to this:

…

--------- mime boundary <html> <head/> <body> <p>Hi John,</p> <p>can we meet this afternoon?</p> <p>&nbsp;</p> <p>Bill</p> <div class="white-text white-background" style="width=1px;height=1px;"> -----BEGIN PGP MESSAGE----- hQEMAzH7R5BvNZFFAQgApG8xYn8K1b5PcHyGjsPXM2FJaX1DFRHuuyG1XForSSS/ v1doZVFUDLy1pc1LwRNzXY6SFXioF6YnRokVFyETqL/Nxa1f+CDzT3IvmeSVAntr [...tons of more gibberish...] /8Ra+Uh+HO7Q8hGMEm28hwWlgKt+tphU3doj1hZPQ7qdlFNSfRqD5t423qxms3/3 FYCxqXKaWB4vPL8rEgnQpyep4osoNyPcWVpndLZeWev0vJg/JI9MV0ziLiJ8YtAP -----END PGP MESSAGE----- </div> <body> </html> --------- mime boundary If the mail client launches the decryption _before_ starting rendering, the user would be prompted for the passphrase, and as a result would come to believe that the very short message was encrypted. IMO, the only defence against this would be to render all unecrypted fragments within a MIME part _before_ launching decryption. In that case, the user would see the short message, and would then be prompted for the passphrase. He would then have the opportunity to opt out of decrypting (by not entering his passphrase). In summary (finally!), the combination of the following five things would seem to me as a useful defence against Efail: 1. strict slicing of MIME parts, and enclaving the processing of each MIME part slice 2. not loading remote resources without expressed user intent (clicking a form link in the message, or typing the command key to load them) 3. loading <a> links in an external browser only 4. sandboxing of HTML processing, and disabling any script execution in the sandbox 5. rendering of all unencrypted fragments of a MIME part _before_ launching decryption It seems to me, that astroid does nr. 1, 2, and 3 already. @gauteh is considering nr. 4 anyway. Remains to be determined how much effort nr. 5 will be? Detect PGP boundaries, remember PGP fragment locations, remove PGP fragments, render remainder, decrypt each PGP fragment in turn, reinsert cleartexts at remembered locations, render again, done.