Serious vulnerabilities with OpenPGP and S/MIME [LWN.net]

The efail.de site describes a set of vulnerabilities in the implementation of PGP and MIME that can cause the disclosure of encrypted communications, including old messages. "In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs."

The EFF recommends uninstalling ~~email-encryption~~ tools that automatically decrypt email entirely. "Until the flaws described in the paper are more widely understood and fixed, users should arrange for the use of alternative end-to-end secure channels, such as Signal, and temporarily stop sending and especially reading PGP-encrypted email."

to post comments

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 13:10 UTC (Mon) by corsac (subscriber, #49696) [Link] (3 responses)

Hi Jonathan,

please *dont* realy the EFF recommandation, which doesn't make any sense. In the attack scenario published by the paper, the attacker already has access to the encrypted mails (either by way of MITM or because it has server access) and modifies the mails to force the client to disclose the plaintext to an attacker-controled server.

If you follow the EFF recommandation and disable encryption, then the attacker has directly access to the plaintext and doesn't even need any attack.

So please, can you drop that line from the article? It doesn't make any sense.

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 13:12 UTC (Mon) by andreicek (guest, #122135) [Link] (2 responses)

For anyone reading it's enough to disable automatic decryption for now AFIK.

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 13:25 UTC (Mon) by jonathon (guest, #107301) [Link] (1 responses)

From the page:

> disable and/or uninstall tools that automatically decrypt PGP-encrypted email

Disabling tools that "automatically decrypt" is not the same as "uninstalling email-encryption tools entirely".

According to https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06..., the vulnerability primarily involves HTML email automatically loading remote content.

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 13:27 UTC (Mon) by andreicek (guest, #122135) [Link]

Thanks for the clarification!

HTML mail

Posted May 14, 2018 13:52 UTC (Mon) by epa (subscriber, #39769) [Link] (10 responses)

Does anyone who takes security seriously bother with HTML mail to start with? Plain text has none of these problems.

HTML mail

Posted May 14, 2018 14:04 UTC (Mon) by smurf (subscriber, #17840) [Link] (1 responses)

Exactly. Instead of de-installing auto-decrypt tools, simply turn off the HTML viewer and the auto-decrypt feature. Then, on any email you get, either view-as-HTML or decrypt, but *never* do both.

Problem solved, at least until the underlying issues get fixed. It's not exactly rocket science to partition MIME parts so that the sort of boundary violation described here cannot happen in the first place.

HTML mail

Posted May 14, 2018 15:00 UTC (Mon) by hkario (subscriber, #94864) [Link]

one of the reasons why I like kmail so much, not only I can configure it to show text mode messages by default, even if I click it to show me the HTML version, it will not load remote resources by default

(it may be the configuration I'm running, but just having that option is really nice)

HTML mail

Posted May 14, 2018 14:40 UTC (Mon) by flussence (guest, #85566) [Link] (3 responses)

Does anyone use encrypted email regularly enough for this to be a threat? I'd have thought the amount of cleartext metadata being sprayed everywhere would render it a pointless endeavour nowadays.

HTML mail

Posted May 14, 2018 17:35 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

I have received vulnerability disclosures via PGP encrypted email every now and then.

HTML mail

Posted May 14, 2018 18:17 UTC (Mon) by excors (subscriber, #95769) [Link]

I like the note in this article where they sent a PGP-encrypted message to Phil Zimmermann, creator of PGP, who replied: "I cannot decrypt this on my iphone. Please send this to me again, as plaintext."

Still, I guess there are bound to be some people willing to jump through the necessary hoops to use PGP for email properly, and perhaps some of them do so because they actually need the security rather than just because they enjoy being awkward, and this vulnerability would matter to them.

HTML mail

Posted May 23, 2018 14:57 UTC (Wed) by wookey (guest, #5501) [Link]

I get a reasonable amount of encrypted mail, yes. Probably almost none of that is multipart-HTML though. That is an unusual combination.

HTML mail

Posted May 14, 2018 22:17 UTC (Mon) by pboddie (guest, #50784) [Link] (1 responses)

Maybe I missed something, but in the "direct exfiltration" attack, the mail client apparently needs to effectively glue the parts together to display them as a single HTML document. Why would any mail client actually do this? Each part is, after all, a separate document. You wouldn't take three image parts and merge them, so what would be different here?

HTML mail

Posted May 15, 2018 12:31 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Yes, I was wondering that myself. The HTML trick should never have worked.

HTML mail

Posted May 14, 2018 22:39 UTC (Mon) by k8to (guest, #15413) [Link]

We're now at the point where I regularly get mails that are completely broken in their text components. http links with layered encoding errors while malforming the text part of the message.

It's really sad how companies whose entire business is based around sending emails can't be bothered to get their emails intact. These days I'm frequently forced to resort to manually parsing bits of html out of the raw bytes of the html part of the email to do my job without exposing myself to risks.

I'm doubtful most people would be able to do this even if they understood the risks.

HTML mail

Posted May 15, 2018 1:14 UTC (Tue) by pabs (subscriber, #43278) [Link]

> Plain text has none of these problems.

I wouldn't be so sure about that, it completely depends on what rendering technology is used and if it is being used correctly. ISTR some X.509 vulnerability in a browser because they used Qt rich-text controls instead of plain-text ones.

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 14:06 UTC (Mon) by Sesse (subscriber, #53779) [Link] (2 responses)

It's a bit sad that OpenPGP still doesn't use authenticated encryption.

Also: Please, when fixing this in the spec, it would also be nice to have a multicore-capable mode! Some of us GPG-encrypt our backups. :-)

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 14:13 UTC (Mon) by unixbhaskar (guest, #44758) [Link]

This seems to be a mandatory stuff and I do " Some of us GPG-encrypt our backups". GPG/PGP become such an important cog in the wheel that our work most of the time depend on it.

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 14:14 UTC (Mon) by cortana (subscriber, #24596) [Link]

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

[...] OpenPGP [...] started to use authenticated encryption (AE) since 2000 or 2001. Our AE is called MDC (Modification detection code) and was back then introduced for a very similar attack. Unfortunately some OpenPGP implementations were late to introduce MDC and thus GPG could not fail hard on receiving a mail without an MDC. However, an error is returned during decrypting and no MDC is used:

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 14:23 UTC (Mon) by karkhaz (subscriber, #99844) [Link] (1 responses)

My initial thought on how to mitigate this entire class of attacks in the future was: if the email is encrypted but unsigned, or if the signature doesn't check out, then don't decrypt or display the email and warn the user. But the vulnerability FAQ states:

"Will signatures prevent these attacks?

No. PGP and S/MIME emails are displayed in the email program independently of whether or not they are signed or whether an existing signature is valid or not. Even if signatures did matter: an attacker can copy the altered ciphertext into a separate email and create a valid signature under his own name."

Therefore in addition, we need mail clients to warn the user if the email is signed by somebody other than the person in the sender field. Even then, the user might not notice if they were expecting email from larry@gmail.com and received email whose From: and signature are both from larry@gmail.corn, since they look fairly similar.

So in summary, mail clients could do this:

- If the email is encrypted but unsigned, don't decrypt the email and warn the user

- If the email is encrypted and the signature doesn't validate, don't decrypt the email and warn the user

- If the address of the signature is different from the From: field in the email header, don't decrypt the email and warn the user

- (paranoid level 11) if the address in the From: field is very similar to an address that you have already Trusted on First Use, then don't decrypt the email and warn the user.

good advice

Posted May 18, 2018 2:05 UTC (Fri) by johnjones (guest, #5462) [Link]

"So in summary, mail clients could do this:
- If the email is encrypted but unsigned, don't decrypt the email and warn the user
- If the email is encrypted and the signature doesn't validate, don't decrypt the email and warn the user
- If the address of the signature is different from the From: field in the email header, don't decrypt the email and warn the user
- (paranoid level 11) if the address in the From: field is very similar to an address that you have already Trusted on First Use, then don't decrypt the email and warn the user."

yes agree completely

Serious vulnerabilities with OpenPGP and S/MIME

Posted May 14, 2018 14:26 UTC (Mon) by mricon (subscriber, #59252) [Link]

EFF is recommending that people stop using PGP and switch to Signal, completely ignoring the fact that:

1. The problem is in email tooling, not PGP or GnuPG's implementation.
2. Signal had a Remote Code Execution bug in its desktop client literally just last week (CVE-2018-1000136), so it's not like it's magically immune from tooling problems.

I'm not here to dump on Signal -- I use it daily, and it's well-done client with acceptable usability-vs-security trade-offs. However, PGP and Signal do not share the exact same niche -- PGP is fully decentralized and doesn't require any available networking nodes (i.e. you can exchange PGP-encrypted messages via homing pigeons), whereas Signal (the messenger client, not the protocol) must be able to contact its network of relays for any two parties to communicate.

Anyway, I would say PGP is mostly used for code signing, not for encrypted communication -- simply because key management is one of those Hard Problems and doing it in a way that is both secure AND usable is proving to be near-impossible to get right.

Gpg4win statement

Posted May 18, 2018 7:46 UTC (Fri) by ber (subscriber, #2142) [Link]

The Gpg4win Team (which I am a part of) has prepared a statement about the research findings and the related media coverage: gpg4win.de/statement-efail.html