LWN: Comments on "Serious vulnerabilities with OpenPGP and S/MIME"

HTML mail

wookey — Wed, 23 May 2018 14:57:16 +0000

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

Gpg4win statement

ber — Fri, 18 May 2018 07:46:55 +0000

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

good advice

johnjones — Fri, 18 May 2018 02:05:34 +0000

"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

HTML mail

dskoll — Tue, 15 May 2018 12:31:54 +0000

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

HTML mail

pabs — Tue, 15 May 2018 01:14:18 +0000

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

HTML mail

k8to — Mon, 14 May 2018 22:39:04 +0000

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

pboddie — Mon, 14 May 2018 22:17:42 +0000

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

excors — Mon, 14 May 2018 18:17:11 +0000

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

pbonzini — Mon, 14 May 2018 17:35:15 +0000

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

HTML mail

hkario — Mon, 14 May 2018 15:00:03 +0000

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

flussence — Mon, 14 May 2018 14:40:32 +0000

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.

Serious vulnerabilities with OpenPGP and S/MIME

mricon — Mon, 14 May 2018 14:26:55 +0000

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.

Serious vulnerabilities with OpenPGP and S/MIME

karkhaz — Mon, 14 May 2018 14:23:26 +0000

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.

Serious vulnerabilities with OpenPGP and S/MIME

cortana — Mon, 14 May 2018 14:14:48 +0000

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

unixbhaskar — Mon, 14 May 2018 14:13:38 +0000

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

Sesse — Mon, 14 May 2018 14:06:24 +0000

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. :-)

HTML mail

smurf — Mon, 14 May 2018 14:04:13 +0000

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

epa — Mon, 14 May 2018 13:52:58 +0000

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

Serious vulnerabilities with OpenPGP and S/MIME

andreicek — Mon, 14 May 2018 13:27:31 +0000

Thanks for the clarification!

Serious vulnerabilities with OpenPGP and S/MIME

jonathon — Mon, 14 May 2018 13:25:05 +0000

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

andreicek — Mon, 14 May 2018 13:12:04 +0000

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

Serious vulnerabilities with OpenPGP and S/MIME

corsac — Mon, 14 May 2018 13:10:00 +0000

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.