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.

[gauteh]

c-alpha writes on June 7, 2018 16:11:

On 2018-05-27, at 09:34 , Gaute Hope ***@***.***> wrote: > 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. ;-))

Hehe, yeah - good point. It feels too strict to completely forbid remote content in encrypted emails, though I have never received an GPG email with remote-content. And I do not see how anyone in their right mind would send something like that. Still, I think I lean towards forbidden unless explicitly allowed in a config option. Note that you would still have to manually hit `C-i` to load remote content.

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?

I think this is a good idea. If I understand correctly this means putting every mime-part in its own iframe? I think this is more or less what I was thinking about as well. Some notes: * Attachments will still be listed at the end. But here the HTML is generated completely by us. * Local scripts are currently allowed because they are used to do syntax highlightning. We might have to change this to a library. The good thing about google prettify is that it can detect programming language, this is usually not possible.

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

I don't think this is legal PGP/MIME which is the only thing we support currently. So it would not appear to be encrypted. Additionally, if the content was hidden in some legal mime structure I do not think it would show in astroid since the encryption bar (on the left) would not extend across the content. I have not tested though. Maybe you've found a new variant of the EFAIL attack ;)

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.

Good point, if legal structure, user might think it is encrypted even though the visible encryption context shows otherwise.

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).

By using separate iframes / contexts / non-flat-HTML structure this should not be a problem. Especially, since we do not support inline PGP (#289). If we do decide to support inline PGP at some point this means that the inlined PGP must be rendered in its own iframe.

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.

I do think that 1 - 4 is sufficient, these are also easier to accomplish. 4 I think will give the greatest benefit and should be the priority. 5 I think requires too much effort for gain at the moment? It could easily lead to a convuluted user experience / hard to get right programatically.

[c-alpha]

On 2018-06-08, at 09:09 , Gaute Hope ***@***.***> wrote: [...] It feels too strict to completely forbid remote content in encrypted emails,

Fully agree.

though I have never received an GPG email with remote-content. And I do not see how anyone in their right mind would send something like that.

I had very similar thoughts when writing my comment yesterday. But then I thought of a calendar invite, which I did receive encrypted once. It had HTML content with accept/decline buttons for the appointment. So I think there are a select,few valid use cases involving accessing remote resources, BUT never without expressed user intent.

Still, I think I lean towards forbidden unless explicitly allowed in a config option. Note that you would still have to manually hit `C-i` to load remote content.

Agreed. Hitting C-i, or clicking on the "accept" button is what I meant by "expressed user intent". If these were turned off by default, users might be frustrated quickly? IMO, allowing http requests as a consequence of C-i or button click should reasonably be considered very low risk, if, and only if, absolutely no script execution happens. In this mode, only data which the sender provided himself in the first place is sent to the server. Thus, the worst case would seem to be a tracking-type attack. If the attacker includes some unique ID in the request data, he will be able to infer that user X is online, and has his email client open. Without script execution, no data on the user's system could be accessed or copied. To me it would hence seem that the no-scripts-approach could be a compromise solution, still allowing the convenience of loading remote resources (stationery pictures and CSS) upon request and being able to click links, but yet limiting the remaining risk to being tracked (which would seem tolerable to me). This is independent of whether the message is encrypted or not, btw.

> 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? I think this is a good idea. If I understand correctly this means putting every mime-part in its own iframe? I think this is more or less what I was thinking about as well.

I wasn't thinking of iframe, but thats very well possible, of course. I started from the boundary interleaving idea in Efail:

--------- mime boundary -----BEGIN PGP MESSAGE----- --------- mime boundary -----END PGP MESSAGE----- --------- mime boundary [...] If we copy everything between two MIME boundaries to a separate buffer, and then process that copied part of the data only, we get a GPG error, because either the beginning or the end of the PGP block is missing. Other mail clients work on the complete mail buffer only. In a first pass, they detect the MIME boundaries to display attachment indicators in the UI etc. And then the client removes some/all of the MIME boundaries from the buffer to prevent them from messing up the HTML rendering. This is necessary, since the client works with a single buffer per message only. Then, in a second pass on this buffer, the client looks for PGP blocks. IMO, this is clearly an - unfortunately common - mail client design flaw. There clearly is a containment hierarchy between MIME parts and PGP blocks. MIME parts come first, and they can contain PGP blocks. Mail clients however take a shortcut by trying to do everything in a single buffer only, but which breaks the containment hierarchy. That's waht I meant by "slicing" and "enforcing the MIME parts structure". Putting each MIME part in a separate, sandboxed iframe seems like a convenient way of mimicking the same structure in the UI. We could then even have each MIME part be rendered by a separate thread into its own iframe.

Some notes: [...] * Local scripts are currently allowed because they are used to do syntax highlightning. We might have to change this to a library. The good thing about google prettify is that it can detect programming language, this is usually not possible.

How are these scripts launched? Do you insert stuff in the message HTML (e.g. onLoad()), or wrap the message HTML? However it's done technically, any scripts launched by android to improve content rendering must ensure that they do not execute any scripts embedded in the message HTML.

[...] I don't think this is legal PGP/MIME which is the only thing we support currently. So it would not appear to be encrypted.

I haven't checked.

Additionally, if the content was hidden in some legal mime structure I do not think it would show in astroid since the encryption bar (on the left) would not extend across the content. I have not tested though. Maybe you've found a new variant of the EFAIL attack ;)

I'm trying to anticipate what the next step of an attacker or security reseracher could be. IMO, the most likely counter measure by affected, other mail clients will be to enforce the MIME part/PGP block containment hierarchy (like astroid does already), which will lead to GPG decryption errors, hinting to something suspicious, and preventing the rogue script from obtaining the cleartext. Seems the most effective, an dat the same time least burdensome response. Hence, the next step for the attacker to get past this countermeasure, will be to craft the message with a legal MIME/PGP structure, but still leverage on the PGP auto-detection and auto-detection by inserting a PGP block as an "invisible" HTML. To protect against thi ssecond stage, all execution of scripts in the message HTML must be prevented.

> 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. Good point, if legal structure, user might think it is encrypted even though the visible encryption context shows otherwise.

Yep.

> 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). By using separate iframes / contexts / non-flat-HTML structure this should not be a problem. Especially, since we do not support inline PGP (#289). If we do decide to support inline PGP at some point this means that the inlined PGP must be rendered in its own iframe. > [...] > 5. rendering of all unencrypted fragments of a MIME part _before_ > launching decryption > [...] I do think that 1 - 4 is sufficient, these are also easier to accomplish. 4 I think will give the greatest benefit and should be the priority. 5 I think requires too much effort for gain at the moment? It could easily lead to a convuluted user experience / hard to get right programatically.

Now I'm confused. First you say "looks feasible, and then not? How would the UX be "convoluted"? I open the message, I see some readable parts of the message (which were not encrypted), and a placeholder block showing a closed padlock and "encrypted part". Then, the passphrase prompt pops up. Would work for me at least?

[gauteh]

c-alpha writes on June 8, 2018 15:00:

On 2018-06-08, at 09:09 , Gaute Hope ***@***.***> wrote: > though I have never received an GPG email with remote-content. And I > do not see how anyone in their right mind would send something like > that. I had very similar thoughts when writing my comment yesterday. But then I thought of a calendar invite, which I did receive encrypted once. It had HTML content with accept/decline buttons for the appointment. So I think there are a select,few valid use cases involving accessing remote resources, BUT never without expressed user intent.

Do you mean that these buttons are images or that some URL is opened when you click them?

> Still, I think I lean towards forbidden unless explicitly allowed in > a config option. Note that you would still have to manually hit `C-i` > to load remote content. Agreed. Hitting C-i, or clicking on the "accept" button is what I meant by "expressed user intent".

A user action, like clicking a link is always allowed - but it will be opened in a browser outside of astroid. If we were susceptible to EFAIL, this could in theory be used in the same way as a remote-image - but would require a user-action. User-actions are strictly separated from script-actions by webkit.

> > 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? > > I think this is a good idea. If I understand correctly this means > putting every mime-part in its own iframe? I think this is more or > less what I was thinking about as well. I wasn't thinking of iframe, but thats very well possible, of course. I started from the boundary interleaving idea in Efail: --------- mime boundary -----BEGIN PGP MESSAGE----- --------- mime boundary -----END PGP MESSAGE----- --------- mime boundary [...] If we copy everything between two MIME boundaries to a separate buffer, and then process that copied part of the data only, we get a GPG error, because either the beginning or the end of the PGP block is missing. Other mail clients work on the complete mail buffer only. In a first pass, they detect the MIME boundaries to display attachment indicators in the UI etc. And then the client removes some/all of the MIME boundaries from the buffer to prevent them from messing up the HTML rendering. This is necessary, since the client works with a single buffer per message only. Then, in a second pass on this buffer, the client looks for PGP blocks. IMO, this is clearly an - unfortunately common - mail client design flaw. There clearly is a containment hierarchy between MIME parts and PGP blocks. MIME parts come first, and they can contain PGP blocks. Mail clients however take a shortcut by trying to do everything in a single buffer only, but which breaks the containment hierarchy. That's waht I meant by "slicing" and "enforcing the MIME parts structure". Putting each MIME part in a separate, sandboxed iframe seems like a convenient way of mimicking the same structure in the UI. We could then even have each MIME part be rendered by a separate thread into its own iframe.

I do not think we are vulnerable to this. We process each MIME part separately, and we would therefore not even realize that the message is encrypted.

> Some notes: > [...] > * Local scripts are currently allowed because they are used to do > syntax highlightning. We might have to change this to a library. The > good thing about google prettify is that it can detect programming > language, this is usually not possible. How are these scripts launched? Do you insert stuff in the message HTML (e.g. onLoad()), or wrap the message HTML? However it's done technically, any scripts launched by android to improve content rendering must ensure that they do not execute any scripts embedded in the message HTML.

They're added in the header. There is definitely room for improvement here.

> > [...] > > 5. rendering of all unencrypted fragments of a MIME part _before_ > > launching decryption > > [...] > > I do think that 1 - 4 is sufficient, these are also easier to > accomplish. 4 I think will give the greatest benefit and should be > the priority. 5 I think requires too much effort for gain at the > moment? It could easily lead to a convuluted user experience / hard > to get right programatically. Now I'm confused. First you say "looks feasible, and then not? How would the UX be "convoluted"? I open the message, I see some readable parts of the message (which were not encrypted), and a placeholder block showing a closed padlock and "encrypted part". Then, the passphrase prompt pops up. Would work for me at least?

That could work, but it would probably be quite annoying since in most encrypted emails the entire message is encrypted and you would always just have to do something manually to decrypt the message every time. I am more in favour of trying to secure against this attack using separate iframes (especially for the encrypted parts, since the efail attack isn't really relevant for non-encrypted emails).

[c-alpha]

[...]

though I have never received an GPG email with remote-content. And I
do not see how anyone in their right mind would send something like
that.

I had very similar thoughts when writing my comment yesterday. But
then I thought of a calendar invite, which I did receive encrypted
once. It had HTML content with accept/decline buttons for the
appointment. So I think there are a select,few valid use cases
involving accessing remote resources, BUT never without expressed user
intent.

Do you mean that these buttons are images or that some URL is opened
when you click them?

They are not images, but trigger HTTP requests. The actual format of CalDAV transactions can be seen in the examples in RFC 6638, appendix B. Since these cannot directly be generated from an HTML message without JavaScript, the accept/decline buttons trigger GET requests over https to URLs on the calendar server of the meeting organiser, with parameters containing a hash or two of sorts identifying the meeting and attendee, and the attendee's decision.

When I invite myself to an event on my icloud.com - for instance - I get an HTML email like this:

You see an ICS attachment (bottom left), and three convenience buttons. The <a> link behind the "accept" button for example is:

https://www.icloud.com/calendar/eventreply/en-gb/?t=2_GI3TIMBYG44DCMJSG42DAOBXHBA7JTCOPYPGOMM4CTDYFNSC2HAZQIR3R6EPLQBSIH66TIQMLBEC6&p=&cc=DE#reply=accept

When I click that, it is opened in the browser, and the response page is this:

Something like this, combined with a corporate email gateway that encrypts outgoing emails for everyone whose public key is available, will lead to an encrypted message where the resulting cleartext is HTML containing links to external stuff.

[...]

How would the UX be "convoluted"? I open the message, I see some
readable parts of the message (which were not encrypted), and a
placeholder block showing a closed padlock and "encrypted part". Then,
the passphrase prompt pops up. Would work for me at least?

That could work, but it would probably be quite annoying since in most
encrypted emails the entire message is encrypted and you would always
just have to do something manually to decrypt the message every time.

Agreed.

I think we should ban inline PGP from astroid altogether, btw (see here and here). Although PGP/MIME is known to be unsupported by some older email clients, I'd value the privacy and security improvements of PGP/MIME and consider them to be more important than compatibility with clients that have limited MIME compatibility.

I am more in favour of trying to secure against this attack using separate
iframes (especially for the encrypted parts, since the efail attack
isn't really relevant for non-encrypted emails).

Fully agree.

[gauteh]

c-alpha writes on June 12, 2018 15:50:

> Do you mean that these buttons are images or that some URL is opened > when you click them? They are not images, but trigger HTTP requests. [...]

Ok, so they are essentially just links with images. These should already be working, and I do not think they present a security risk. Especially if we use iframes to separate MIME parts. Does the invite work without the images displayed? Are they included as CID's or are they remote resources?

I think we should ban inline PGP from astroid altogether, btw (see [here](https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/) and [here](https://wiki.gnupg.org/SignatureHandling)). Although PGP/MIME is known to be unsupported by some **older** email clients, I'd value the privacy and security improvements of PGP/MIME and consider them to be more important than compatibility with clients that have limited MIME compatibility.

This is already the case :) See #289.

[c-alpha]

On 2018-06-12, at 16:12 , Gaute Hope ***@***.***> wrote: c-alpha writes on June 12, 2018 15:50: >> Do you mean that these buttons are images or that some URL is opened >> when you click them? > > They are not images, but trigger HTTP requests. [...] Ok, so they are essentially just links with images.

Yes.

These should already be working, and I do not think they present a security risk. Especially if we use iframes to separate MIME parts.

Yes, since we're not executing any scripts, passing URLs to a browser for opening should be considered safe.

Does the invite work without the images displayed?

Yes. The "accept", "decline", and "maybe" are text content of an anchor node (<a ...>Accept</a>).

Are they included as CID's or are they remote resources?

They are remote resources. The checkmark on the "accept" button for instance is here: https://statici.icloud.com/emailimages/v4/common/new/btn_accept@2x.png

> I think we should ban inline PGP from astroid altogether, btw (see > [here](https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/) and > [here](https://wiki.gnupg.org/SignatureHandling)). Although PGP/MIME > is known to be unsupported by some **older** email clients, I'd value > the privacy and security improvements of PGP/MIME and consider them to > be more important than compatibility with clients that have limited > MIME compatibility. This is already the case :) See #289.

Cool! There is a risk associated even with accepting inline PGP (see the fifthhorseman.net link), via message tampering through header substitution. I would consider it a small risk, however, since to use it intentionally, one would need to find one byte sequence, which yields sensible content under two different character encodings. In summary, it would hence seem to me, that the convenience of being able to render old encrypted emails, or ones sent by legacy clients, outweighs the risk induced by parsing inline PGP.

[gauteh]

c-alpha writes on June 12, 2018 16:39:

On 2018-06-12, at 16:12 , Gaute Hope ***@***.***> wrote: > Does the invite work without the images displayed? Yes. The "accept", "decline", and "maybe" are text content of an anchor node (<a ...>Accept</a>).

Good, so we can simply disable remote-content in encyrpted emails without significant loss of functionality or convenience in this case.

There is a risk associated even with accepting inline PGP (see the fifthhorseman.net link), via message tampering through header substitution. I would consider it a small risk, however, since to use it intentionally, one would need to find one byte sequence, which yields sensible content under two different character encodings. In summary, it would hence seem to me, that the convenience of being able to render old encrypted emails, or ones sent by legacy clients, outweighs the risk induced by parsing inline PGP.

We do not parse or attempt to decrypt inline PGP at all -- only PGP/MIME. I did not even consider supporting sending inline PGP :)

[c-alpha]

On 2018-06-12, at 16:46 , Gaute Hope ***@***.***> wrote: > The "accept", "decline", and "maybe" are text content of an anchor node (<a ...>Accept</a>). Good, so we can simply disable remote-content in encyrpted emails without significant loss of functionality or convenience in this case.

Yes. (ok, loss of convenience yes, but still performs the basic function) IMO, any reasonably useful application should always be able to achieve the intended function without relying on optional features (such as e.g. downloading remote resources). Optional features may be used for more convenience, but anything that requires me to activate such optional features to achieve the most basic functions, is either idiotic design (do you hear me, ieee.org?), or outright malicious. I hence fully agree with simply disabling remote content in encrypted messages.

[...] We do not parse or attempt to decrypt inline PGP at all -- only PGP/MIME. [...]

I read your remark "Good news! GMime gets inline PGP in version 3.0" in #289 as potentially indicative of some intention to support reading inline PGP. That's not the case, which is good news to me. Thanks for clarifying!

[gauteh]

c-alpha writes on June 12, 2018 17:03:

I hence fully agree with simply disabling remote content in encrypted messages.

Good!

> [...] > We do not parse or attempt to decrypt inline PGP at all -- only > PGP/MIME. > [...] I read your remark "Good news! GMime gets inline PGP in version 3.0" in #289 as potentially indicative of some intention to support reading inline PGP. That's not the case, which is good news to me. Thanks for clarifying!

Yes, it was. Reading, but not sending. I still think it can be done safely, with the same precautions as for PGP/MIME. But I doubt it is worth the hassle :) The problem is not so much current e-mail clients sending inline PGP as being able to read old - pre PGP/MIME - encrypted emails.

[gauteh]

#455 now uses IFRAMEs for showing all parts. Both HTML and TEXT. It is now also possible to toggle between the parts without re-opening the message, configuration options allow you to configure default part other than plain and also to show html part if that is the only part.

[c-alpha]

Apologies for the aftermath, but this just in. Apple have declared victory on efail by "improving isolation of MIME" in their mail apps in macOS High Sierra 10.13.5, Security Update 2018-003.

Mail
Available for: macOS High Sierra 10.13.4
Impact: An attacker may be able to exfiltrate the contents of
S/MIME-encrypted e-mail
Description: An issue existed in the handling of encrypted Mail. This
issue was addressed with improved isolation of MIME in Mail.
CVE-2018-4227: Damian Poddebniak of Münster University of Applied
Sciences, Christian Dresen of Münster University of Applied Sciences
, Jens Müller of Ruhr University Bochum, Fabian Ising of Münster
University of Applied Sciences, Sebastian Schinzel of Münster
University of Applied Sciences, Simon Friedberger of KU Leuven, Juraj
Somorovsky of Ruhr University Bochum, Jörg Schwenk of Ruhr
University Bochum

In that light, I would think it's safe to claim that android is not vulnerable.