Critical PGP Vulnerability

EFF is reporting that a critical vulnerability has been discovered in PGP and S/MIME. No details have been published yet, but one of the researchers wrote:

We’ll publish critical vulnerabilities in PGP/GPG and S/MIME email encryption on 2018-05-15 07:00 UTC. They might reveal the plaintext of encrypted emails, including encrypted emails sent in the past. There are currently no reliable fixes for the vulnerability. If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now.

This sounds like a protocol vulnerability, but we’ll learn more tomorrow.

News articles.

Tags: cryptanalysis, cryptography, email, encryption, PGP, protocols, vulnerabilities

Posted on May 14, 2018 at 9:33 AM • 26 Comments

Comments

Vincent Archer • May 14, 2018 9:45 AM

The details were increasingly discussed so the full disclosure has been advanced:

https://efail.de/ (includes general discussion and full paper)

There’s two distinct attacks, a very basic one and a more sophisticated version. Table of vulnerable software at the end of the paper is important.

Ratio • May 14, 2018 9:46 AM

Obligatory site with logo, paper, etc. No merch or theme song tho.

Dave • May 14, 2018 9:57 AM

It’s not critical, it’s mostly media hype. See e.g. https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html.

RealFakeNews • May 14, 2018 10:02 AM

If this exposes PAST messages, then isn’t it beyond “critical”, and more “disastrous”?

@Dave: a case of “we can’t break it so we’ll scare everyone away from it”?

Vesselin Bontchev • May 14, 2018 10:04 AM

EFF’s report is bullshit. Unless you’re using S/MIME (does anyone use that outside in-company environments?), all you have to do is make sure that your GnuPG and GPG e-mail plug-in (e.g., Enigmail for Thunderbird) is up-to-date. Don’t panic, don’t uninstall anything, keep using encrypted e-mail. This is an over-hyped issue.

RealFakeNews • May 14, 2018 10:04 AM

@Dave: your link is broken (404).

Doug Barton • May 14, 2018 10:06 AM

These are side-channel attacks that rely on the attacker having access to the encrypted message, and the receiver of the message viewing HTML mail AND downloading remote images by default. The latter has been advised against since the earliest days of HTML mail to avoid tracking, and other potentially malicious activity.

It has also long been stated in PGP circles that HTML mail is incompatible with PGP, and while some still like to use it, for the most part it is not used by folks with genuine security needs.

And it’s also worth noting that some of us have been saying for many years that PGP/MIME is dangerous, in large part because the MIME standard does not have security as a focus, and is interpreted by different clients in vastly different ways.

In short, if you have an actual need to send e-mail with an encrypted message body; stick with PGP, and plain text sending and viewing.

Czerno • May 14, 2018 10:07 AM

We/I don’t do HTML in email, encypted or not, sent or received. (Actually, IMhO, nobody should send html emails, ever, in addition everyone should setup their email client to show the plain-text version only in received messages). At a glance I guess this means not vulnerable. Non-issue, then AFAIAC.

Vesselin Bontchev • May 14, 2018 10:12 AM

@RealFakeNews It exposes past messages if and only if all of the following holds:

1) You are using an oudated GnuPG or GPG e-mail plug-in (e.g., an old version of Enigmail).

2) Your e-mail client is configured to render HTML e-mails.

3) Your e-mail client is configured to render foreign links in the said HTML e-mails. (This is off by default.)

3) The attacker already has copies of your old encrypted messages. (The attack won’t get them from your mailbox.)

4) The attacker sends you these old e-mails.

5) The plaintext form of these e-mails doesn’t contain any quote characters, or closing HTML brackets, or anything else that could throw off the attack.

6) You decrypt them.

At this point the attacker has the contents of the message. You must also be an idiot, in order not to get suspicious when strangers are sending you old e-mails from other people that don’t decrypt properly (for you – you see a broken image or some other broken HTML tag).

A state-sponsored attacker who is able to hack your e-mail server (or any of the computers that deliver the e-mail to it) and modify the e-mail messages in transit, can also read your encrypted e-mails in real time, as you decrypt them.

AcBeKo • May 14, 2018 10:13 AM

@Vesselin Bontchev: Enigmail now also supports S/Mime

The Federal Office for Information Security provides some infos here:
hxxps://www.bsi.bund.de/EN/TheBSI/thebsi_node.html
and here
hxxps://www.bsi.bund.de/EN/Service/Information/article/efail_vulnerabilities_14052018.html
Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels (draft 0.9.0)
hxxps://efail.de/efail-attack-paper.pdf

Evan • May 14, 2018 11:36 AM

It’s also worth pointing out that the free software implementation of PGP, Gnu Privacy Guard, was apparently completely left out of the loop on this vulnerability but still asked to keep quiet until the embargo was lifted. Is it just me, or is this kind of churlish behavior on the part of vulnerability researchers becoming more common? I recall similar conflicts with OpenBSD and the WPA2 key reinstallation attack, and several open-source OSes not being informed about Spectre and Meltdown. Is this the beginning of a two-tiered system where “responsible disclosure” consists of researchers picking and choosing favorites that will be able to have patches ready when the public announcement is made?

echo • May 14, 2018 12:00 PM

I read the paper linked to by Ratio in the squid topic. Unless I am reading things wrong the biggest worry is the confidentiality of both encrypted and plain text messages can be compromised by cute html tricks with how email clients default processes and failure to catch html issues over several lawyers. These tricks require the user to accept installation defaults or click on the message so it’s not a guarenteed to be sucessful attack? The compromising of PGP/GPG and S/MIME encryption processes rides on the back of this? Isn’t this like saying that a lock was defeated because the door was leftopen?

Major • May 14, 2018 12:05 PM

The efail folks seem to want to make this a CBC problem but clearly this is a MAC problem. Secure encryption includes a message authentication code that ensures that the ciphertext has not been altered in any way.

This should stop any efail attack in its tracks. But doesn’t GPG use public keys? So they should be using PKI to create a one time symmetric key that is irretrievable?

Now I can imagine that this is hard thing to do while keeping the message in an email format in one’s mailbox and especially with embedded access to the outside world with html.

SO DON’T DO IT

The gadget attack is absolutely nothing new. It is a basic observation that helped lead to the conclusion that cipher systems are not secure if the opponent is allowed to create new ciphertexts from old ones. Hence MACs.

Bob • May 14, 2018 12:18 PM

From what I can tell, this comes across as an implementation bug.

Hmm • May 14, 2018 1:25 PM

HTML email should just be fully dropped. If you go in the ocean you’re going to get wet.

Carl 'SAI' Mitchell • May 14, 2018 2:02 PM

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html

Updated GPG link.

IF you’re viewing HTML e-mail, AND have a client that does not check the GPG MDC & fail to display the message, THEN you are vulnerable.

Fixes/workarounds: Turn off HTML e-mail. Switch to / upgrade to a client that checks the MDC.

Ideal fix: GPG/PGP/etc will stop returning the decrypted plaintext when the MDC is absent or incorrect. This will break receiving e-mails from legacy systems, but GPG has had support for it for over a decade. Of course it would be even nicer if OpenPGP/GPG added an option for a modern AEAD mode, but that doesn’t seem necessary to defeat this particular attack.

Nick P • May 14, 2018 2:40 PM

It appears my method of simply GPG-encrypting text or zip files that I email to people is still safe. I specifically chose it to avoid complexity in client side that could cause usability and/or security issues. As a side benefit, the programs that handle text or zip files are much easier to sandbox or run on diverse programs. It comes from being fixed-purpose with minimal user interaction in their workflow.

So, just use GPG in a way that doesn’t trust the mail clients. 🙂

Major • May 14, 2018 5:27 PM

A lot of news seems to want to push users to GCM symmetric and number theory based PKI when these seem to be the least well-understood security-wise.

I feel safest with 256 AES CBC with a SHA256 HMAC afterwards.

Greg • May 14, 2018 6:24 PM

A state-sponsored attacker who is able to hack your e-mail server (or any of the computers that deliver the e-mail to it) and modify the e-mail messages in transit, can also read your encrypted e-mails in real time, as you decrypt them.

I respectfully disagree. The point of an e-mail server is that it’s online 24/7 and will accept connections from pretty much anyone. So, it would be easy for a state-sponsored attacker to access. Or, if you use a third-party/hosted mail service, a nation-state can (with or without a warrant) gain access to the server, to your mailbox or tap the network links.

If you’re doing decryption on your local machine, and you’re taking fairly good precautions, it’s a different matter for that machine to be compromised and side-jacked during decryption.

Not saying it’s impossible by any stretch, but the two attack profiles are different and one does not necessarily imply the other.

Dave • May 14, 2018 8:39 PM

@RealFakeNews: The auto-HTMLisation has merged the period at the end of the sentence with the URL, just delete that and the link will work.

sitaram • May 14, 2018 9:14 PM

People keep saying “turn off HTML”.

You don’t need to do that. You only need to turn off remote image loading.

In Thunderbird, this is called “Show Remote Content”, and defaults to “no”.

I looked at the EFF site as well as the “branded/logo-ed” site for this vuln, and could find no sign of this particular aspect, which makes it a non-issue for most TB users (and I’m willing to bet most other mail clients too).

Vivek • May 15, 2018 2:30 AM

The attack doesn’t work on Mutt – a text-based email client for Unix-like systems.

echo • May 15, 2018 5:54 AM

Can I add one obsersation? For organisations who are sending out email content where the priority is “rich media content” could they make sure the text only version contains the equivalent information and is properly formated?

You get this same binary minded and de-prioritisation of people disabled by blindness too even where statutory obligations exist. This happens with both electronic and paper based media. I have been told Thunderbird is unusable as an email client because it doesn’t handle screenreaders properly.

I am left wondering at times why some organisations are not sued into the ground.

Mark • May 15, 2018 8:37 PM

As usual, a complete over-reaction from the media, including the EFF, similar to Meltdown and Spectre.

I get really sick to death of these reports. Every time I need to calm down some executive who I can usual barely convince to do anything.

Security: The Boy Who Cried Wolf Industry.

Sam Weller • May 16, 2018 2:01 AM

The Modification Detection Code (MDC) packet is a weak point.

Why does the OpenPGP standard offer a mealy-mouthed, non-normative defense of the MDC with its quaint SHA-1 hash and its “modest” security goals? Why does it insist that signing is not always desirable?

Jonathan Wilson • May 16, 2018 5:57 PM

HTML email was a stupid idea in the first place and should never have been invented.

Critical PGP Vulnerability

Comments

Leave a comment Cancel reply