52

There's a lot of talk about EFAIL:

The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs.

So, what should I as an end user do in response to this? Should I immediately stop sending and/or recieving encrypted email? Or perhaps all emails? Or stop using PGP for anything at all? Is there some quick fix? Patches to install? And if so, patches to what? Other actions to take?

Note that this is a question about what to do as an end user. It's not about the inner workings of the vulnerability or how to fix the problem on the protocol level.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • 4
    Yes, I know this question is largely answered in the provided link. But I thought it would be good to address this issue on this site as well, as I suspect there will be a lot of interest in this. – Anders May 14 '18 at 14:00
  • 3
    I wonder whether disabling HTML rendering in email client would help. If you only display message as plaintext, no images will be fetched from remote server, and thus the exploit should not work. – Martin Vegter May 14 '18 at 14:12
  • 4
    [Similar question on Crypto.SE](https://crypto.stackexchange.com/questions/59229/is-the-software-that-uses-pgp-broken-or-is-it-pgp-itself) – Gilles 'SO- stop being evil' May 14 '18 at 19:36
  • 1
    @MartinVegter, likewise wondering (and therefore posting as comment not an answer), but I should think unchecking the "Load Remote Content in Messages" option should be enough. (That still allows HTML rendering, but any remotely hosted images will be left blank and not fetched.) – Wildcard May 14 '18 at 21:57
  • 1
    The real vulnerability is in those app handling both clear and cypher text at the same time ... – Xavier59 May 15 '18 at 06:11
  • @Wildcard - where is this setting "Load Remote Content in Messages" ? – Martin Vegter May 15 '18 at 10:49
  • @MartinVegter that’s its name in Apple Mail. Thunderbird has the setting by a different name; I’m on mobile but can look it up later. What’s your email client? – Wildcard May 15 '18 at 11:15
  • Turning off HTML rendering might not be enough if there are pre-loading mechanisms at work. HTML mail is just used for marketing purposes anyway, so best to throw out all support and go back to good, old plain text. I smile at the banality of this beautifully effective hack and the thousands of security experts who couldn't see the forest for the trees. – forthrin May 17 '18 at 11:55

5 Answers5

34

Notably, PGP is not the problem. The problem lies with the mail handling apps in your browser which you have allowed to use your PGP keys. Those browser apps decrypt the message as they should, but inside that message in addition to your secret is a trojan URL which is an attackers site. Your browser app stupidly tried to connect to the URL which has your secret appended at the end.

For most people the most practical method is (from your link):

Short term: Disable HTML rendering. The EFAIL attacks abuse active content, mostly in the form of HTML images, styles, etc. Disabling the presentation of incoming HTML emails in your email client will close the most prominent way of attacking EFAIL. Note that there are other possible backchannels in email clients which are not related to HTML but these are more difficult to exploit.

Then any URL in the decrypted message will appear as text, including the trojan URL. Almost certainly would you be able to look at the URL and know something was wrong. If nothing was wrong, and if your mail program has a button to to allow you toggle HTML view for that single mail, you would then be able to safely read the mail.

The other method suggested:

Short term: No decryption in email client. The best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client. Start by removing your S/MIME and PGP private keys from your email client, then decrypt incoming encrypted emails by copy & pasting the ciphertext into a separate application that does the decryption for you. That way, the email clients cannot open exfiltration channels. This is currently the safest option with the downside that the process gets more involved.

could be more difficult. On a cell phone it could be very very difficult. On a laptop or desktop, it depends on how easy it would to set up the non-browser app, or have someone do it for you. The fiddly time spent cutting and pasting depends on how many encrypted messages you have to process.

You would also want to be careful that the non-browser app doesn't automatically try to contact the URL.

EDIT: Adding quotes to message won't protect your sent encrypted mail. Thanks to @Anders for pointing out the reference.

Craig Hicks
  • 425
  • 3
  • 6
  • 2
    "mail handling apps in your browser" – isn't this backwards? I understand the vulnerability to be in the 'browser' (HTML parser) in email apps/clients. – Kenny Evitt May 14 '18 at 20:36
  • 1
    One example: Firefox is a browser, and Thunderbird is a client app installed by the user in Firefox. Still no PGP capability. Then the Enigmail add-on is installed onto Thunderbird. Enigmail contains the code that does the decryption, but Thunderbird scans that decrypted result (like an ordinary mail) finds the URLs and automatically tries to display them. So I would say it is the scanning code (HTML parser sounds right) which is called by Thunderbird that is doing the actual leaking. If so, then it Thunderbird that needs to be modified to sandbox the decrypted data. – Craig Hicks May 14 '18 at 21:26
  • Other browser with other email clients (comparable to Thunderbird) may have integrated PGP handling - not requiring an add-on. But the required change is the same: sandbox the decrypted result. – Craig Hicks May 14 '18 at 21:28
  • 17
    @CraigHicks What the heck? Thunderbird is *not* a client app running in Firefox (they at least at some point shared the xulrunner framework). That does not make any sense. It also does not scan the result automatically for URLs or something. It displays the embedded HTML in an embedded browser-like thing. – Jonas Schäfer May 15 '18 at 06:25
  • 4
    Mistakes of crypto engineering in OpenPGP and S/MIME—and generally incoherent security goals—are absolutely _part_ of the problem here. Modern public-key encryption schemes do not admit the selective modification that efail uses to trigger the exfiltration channels; a forger can only replace messages wholesale. – Squeamish Ossifrage May 15 '18 at 12:41
  • 2
    @JonasWielicki - You're right. Thunderbird is a >desktop< email client not a browser email client. Thunderbird should sandbox the decrypted result and scan for URL's or otherwise toxify before "It displays the embedded HTML in an embedded browser-like thing.". – Craig Hicks May 15 '18 at 16:54
  • 1
    @SqueamishOssifrage - You're right. And the OP's link gives that as a necessary long term strategy: """Long term: Update OpenPGP and S/MIME standards. The EFAIL attacks exploit flaws and undefined behavior in the MIME, S/MIME, and OpenPGP standards. Therefore, the standards need to be updated, which will take some time.""" – Craig Hicks May 15 '18 at 16:57
  • Regarding your edit, [efail.de](https://efail.de/#no-quotes) address this and explain why it is not a solution. – Anders May 15 '18 at 18:41
  • 1
    @CraigHicks The reason I made the above comment is that it is misleading to say ‘PGP is not the problem. The problem lies with the mail handling apps…’ when there is a clear problem in PGP (its public-key encryption mechanism fails to provide IND-CCA2; likewise S/MIME, which is hurt even more badly), even if _this particular manifestation_ of that problem arises only in combination with misfeatures downstream in the mailers. – Squeamish Ossifrage May 15 '18 at 18:59
  • @SqueamishOssifrage - It seems to me that the question of whether or not OpenPGP satisfies IND-CCA2 is orthogonal to the existence of EFAIL. EFAIL does not rely on IND-CCA2, it relies on being handed an oracle for free - which is the "free service" provided the faulty mail handling apps. It is true that if OpenPGP is not IND-CCA1 secure, then any keys (keys which have been subject to abuse through the accidental provision of the oracle) are compromised. If OpenPGP is IND-CCA2 secure, then those keys will be safe once the oracle service is shutdown. (continued...) – Craig Hicks May 15 '18 at 20:33
  • (... continuation). The research which uncovered EFAIL doesn't treat the issue of IND-CCA2, it only shows the presence of an oracle. And to repeat myself, that oracle is the fault of the mail client software. Reference for definition of IND-CCA* = https://en.wikipedia.org/wiki/Ciphertext_indistinguishability#Indistinguishability_under_chosen_ciphertext_attack/adaptive_chosen_ciphertext_attack_(IND-CCA1,_IND-CCA2) – Craig Hicks May 15 '18 at 20:38
  • @CraigHicks The attack works by transforming one valid ciphertext into a related valid ciphertext. This is a textbook example of breaking NM-CCA2, which is equivalent to IND-CCA2. There is _another_ problem which is that gpg also starts printing output before verifying the MDC. That's a bug in gpg (‘feature’ that it can be abused to stream decryption of multi-terabyte files), _and_ a bug in the OpenPGP protocol that it doesn't forbid such behavior. My point is not that mailers aren't blameless; my point is it's systemically broken all around, and PGP is _part_ of the problem. – Squeamish Ossifrage May 15 '18 at 20:45
  • @SqueamishOssifrage - I should also have noted that if OpenPGP is not IND-CCA1 secure, then not only are the abused keys no good, but all past messages which were not even passed to the oracle when it was available are now at risk of being decrypted offline. I believe the common assumption is that OpenPGP is at least IND-CCA1 secure. – Craig Hicks May 15 '18 at 20:46
  • @CraigHicks Breaking IND-CCA1 implies nothing about recovering keys. Here's the standard definitions and relations between them: http://www.di.ens.fr/~pointche/Documents/Papers/1998_crypto.pdf – Squeamish Ossifrage May 15 '18 at 20:50
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/77538/discussion-between-craig-hicks-and-squeamish-ossifrage). – Craig Hicks May 15 '18 at 21:18
  • Is the second strategy essentially saying the same thing as the first one? That is, letting the decryption be done by some other program that presumably doesn't render HTML? That's the only way I can imagine it working, but since it seems like the same basic solution, I'm unsure I'm understanding it right. I guess it makes sense if only a small volume of emails are using PGP, since HTML on non-PGP emails doesn't make anything less secure than it already is. – Kat May 17 '18 at 20:18
  • @Kat - The first strategy is to switch off HTML for all mails, encrypted or not. Almost every mail agent has that option and that it why it is suggested. In that case the reader would read the attacking URL as part of the message, but it wouldn't trigger the bug. --- The second strategy is disabling decryption. Then the displayed message is still encrypted so won't contain the URL. But the reader will have to copy and paste (or download) that still encrypted message and decrypt it another way to read it. – Craig Hicks May 17 '18 at 22:56
12

  1. Disable HTML rendering. (Not HTML sending: HTML rendering. It doesn't matter what mail you send; what matters is what your mailer does on receipt of the adversary's mail.)

  2. Consider configuring your mailer to disable automatic PGP key download, S/MIME OCSP verification, S/MIME CRL download, S/MIME intermediate CA download; consider periodically updating your keyrings and certificate stores instead. There's a tradeoff here: You may shoot yourself in the foot by failing to notice revoked certificates and you may deanonymize yourself with batches of related downloads, but your mailer's automatic key download or OCSP verifier or CRL downloader may shoot you in the foot.

  3. Consider disabling automatic decryption in your mailer. There's a tradeoff here: You may shoot yourself in the foot by raising the barrier to communication so high that you don't want to do it any more, but your mailer's automatic decryption may shoot you in the foot.

  4. Follow thegrugq's guide to how to use PGP if you must use PGP for defense against a serious threat model and you're willing to use the command-line gpg tool with all the mental overhead that implies. (Read the OpenSSL man pages if you must use S/MIME, but don't expect the OpenSSL command-line utility to stand to scrutiny…)

  5. If you know anyone connected to OpenPGP or S/MIME development, support their efforts to make them use modern cryptography engineering and articulate meaningful security goals in real-world applications like mailers and package verification, not just the gpg command-line tool. (Don't clamor on Hacker News because humanity has already exceeded its HN hot air quota.)

  6. Use Signal.

  7. Read more details at crypto.se.

Kepotx
  • 822
  • 1
  • 8
  • 16
Squeamish Ossifrage
  • 2,636
  • 8
  • 17
  • 4
    Can you explain what #2 has to do with efail? – Bergi May 15 '18 at 08:08
  • 1
    @Bergi There are several different exfiltration channels. If the attacker edit a partially known message to put an unknown part—say they turn out to be the bytes `0a 1b 2c 3d`—in the position of an OpenPGP key id in the signature, they may be able to cause your mailer to download `http://pool.sks-keyservers.net/pks/lookup?search=0x0a1b2c3d&op=get`. This applies similarly to S/MIME OCSP, CRL, and CA URLs. – Squeamish Ossifrage May 15 '18 at 12:43
  • "You may shoot yourself in the foot by raising the barrier to communication so high that you don't want to do it any more" - I'd call that a win if it means not opening Outlook any more. – Hannah Vernon May 15 '18 at 19:05
9

There is another solution apart from disabling HTML rendering - which you nonetheless should.

This is a list of affected clients and webmailers1:

List of affected clients, webapps and webmailers

The efail attack in its current form relies first and foremost on a client vulnerability. If you are using one of the affected clients, you might want to think about changing to another one for the time being, although that may not be a solution in the long term. Also keep your client and your S/MIME and/or PGP plugin updated. Supposedly Enigmail 2.0 already mitigates Efail.1

{1} https://efail.de/efail-attack-paper.pdf
{2} https://www.heise.de/newsticker/meldung/Efail-Was-Sie-jetzt-beachten-muessen-um-sicher-E-Mails-zu-verschicken-4048988.html

Tom K.
  • 7,913
  • 3
  • 30
  • 53
  • Are all clients/webmailers in that list affected, or should I look at the colors, and if so in which column(s)? –  May 15 '18 at 09:50
  • Below the list are is an explanation of the four symbols that were used. Green means that the client is not affected. Red means that the client is affected without user interaction. – Tom K. May 15 '18 at 10:19
  • So as an example, "Evolution" has one red and three green. Affected or not? Is the S/MIME column relevant, or should only look at PGP? (I honestly don't know...) –  May 15 '18 at 10:24
  • 1. In general: S/MIME and PGP are two different standards for public key encryption (PKE). You can use either one or both (or none). Some clients do not provide interfaces for either one, so an end user has to install plugins. 2. Your specific example: Evolution seems to support both S/MIME and PGP. Furthermore the implementation for S/MIME seems to be affected by the efail attack, while its PGP implementation is not. If you use PGP for encryption and use Evolution as a client, you are - as far as we know now - not vulnerable to the efail attack. If you use S/MIME and Evolution, you are. – Tom K. May 15 '18 at 10:31
6

The current advice is to avoid automatically decrypting the email in your email client. In most cases that means uninstalling the relevant plugin. You then need to copy the encrypted text to a separate application to view it.

You should still be able to send encrypted mail, provided that the receiver is taking the appropriate precautions, although that would probably mean using the problematic plugins.

As per Martin Vetger's comment, disabling automatic html rendering can also largely mitigate the attack, although the researchers also said that there were other channels available that could be exploited with more work.

What that means to you as an end user will vary quite a lot.

In order to benefit from this exploit the attacker has to be able to modify the email message in transit, or resend an email that they have previously captured. Obviously multiple nation states or your employer can do this, but I suspect you are unlikely to find many criminals running a dodgy wi-fi hotspot hoping to grab some sensitive personal information from your PGP emails.

If you are just privacy minded then you could probably just carry on. The email will still be encrypted on the mail server, and GCHQ/NSA etc may be able to grab it, but law enforcement can't use it against you.

You could look to restrict the firewall rules on your machine too, so that the mail client can only communicate on 1 or 2 ports. That would block the html vector completely and potentially cut off a lot of other avenues for exfiltration.

If lives are at stake then abandoning it is best...

ste-fu
  • 1,092
  • 6
  • 9
6

Short term fixes

There are two short term fixes to choose between:

  1. Disable HTML rendering in your email client. (And note that's rendering HTML, i.e. viewing it, not sending it.)
  2. Stop decrypting email in your email client (e.g. by disabling the PGP plugin), and instead copy paste the encrypted data into a separate program to do the decryption.

The EFAIL webpage makes references to potential ways of exfiltrating data without HTML, so just doing #1 might not be completely safe. That is probably why EFF recommends #2 as well. So while #2 is less conveniant, it is probably more secure.

Install updates

Since the vulnerability lies in how email clients interact with PGP, you will want to update your email client and any plugins to it. When the problem is fixed in your email client, you could stop with the short term measures. Both #1 and #2 are reasonable security precautions even in absence of EFAIL, though, so if you gotten into the habit of using them you might as well continue.

OpenPGP or any of it's implementations aren't inherently broken, so while you should always keep your software up to date there is no need to update them specifically because of this. Nor will you have to stop using them.

Remember the other participants

Since both the sender and all recievers can decrypt emails, the EFAIL attack can be directed at any of these. So even if you take the above precautions the messages you send and recieve may still be decrypted if the people you communicate with are less prudent.

For the time being, you may want to take this into consideration before using these tools.

Anders
  • 64,406
  • 24
  • 178
  • 215