
EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME - Foxboron
https://efail.de/
======
tc
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...](https://lists.gnupg.org/pipermail/gnupg-
users/2018-May/060315.html)

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

~~~
jwildeboer
“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.

~~~
dfabulich
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.)

~~~
tptacek
That is _not_ the whole point of piping, and the default behavior of GPG
should be to buffer, validate the MDC, and release plaintext only after it's
been authenticated. Pipes are a standardized Unix interface between processes,
not a solemn pledge to deliver bytes as quickly as possible.

If pipes had the connotation you claim they do, _it would never be safe to
pipe ciphertext_ , because the whole goal of modern AEAD cryptography is never
to release unauthenticated plaintext to callers.

Clients encrypting whole ISO images should expect that decryption will require
a non-default flag. Ideally, GPG would do two-pass decryption, first checking
the MDC and then decrypting. Either way, the vast, commanding majority of all
messages GPG ever processes --- in fact, that the PGP protocol processes ---
should be buffered and checked.

If you have a complaint about how unwieldy this process is, _your complaint is
with the PGP protocol_. The researchers, and cryptographers in general, agree
with you.

~~~
dfabulich
What _is_ the point of piping, in your view? My understanding is that it's a
stream of bytes with backpressure, designed specifically to minimize buffering
(by pausing output when downstream receivers are full/busy).

> If pipes had the connotation you claim they do, _it would never be safe to
> pipe ciphertext,_ because the whole goal of modern AEAD cryptography is
> never to release unauthenticated plaintext to callers.

You say that like it's a reductio ad absurdum, but I think that's essentially
right; you can't do backpressure with unauthenticated ciphertext. You have to
buffer the entire output to be sure that it's safe for further processing.

Thus, if you want to buffer the entire output, don't use a pipe; ask the tool
to generate a file, and then read the file only when the process says that the
file is done and correct.

(I'd say that's a lot more wieldy than two-pass decryption.)

Based on your other remarks about PGP, (nuke it from orbit) I'm not sure you
have any constructive remarks to make on how to improve GPG, but I guess
making it two-pass by default (with a --dangerous-single-pass flag) would be
an improvement.

For normal size emails, users probably wouldn't notice the performance cost of
the second pass, and clients who care about performance at that level can opt
into single-pass decryption and just promise to check the error code.

~~~
tptacek
Backpressure is a _feature_ of Unix pipes. It isn't their raison d'être.

I don't care how you implement it, but any claim that you can't check the MDC
in GPG because it's a piped interface is obviously false. GPG can, like any
number of Unix utilities, some casually written and some carefully written,
simply buffer the data, process it, and write it.

~~~
dfabulich
Nobody said "you can't check the MDC." Everybody said "you have to check GPG's
error code."

And I think it's clear to everybody (in this thread) that GPG's approach is a
dangerous blame-the-user approach to API design, even granting that this
dangerous approach offers optimum performance (especially relative to adding
an entire second pass).

~~~
tptacek
There's no difference. You're talking about the program, I'm talking about the
mechanism. Either way:

* GPG should never release unauthenticated plaintext to callers. The exit code is a red herring.

* Nothing about "pipes" prevents them from squelching unauthenticated plaintext.

------
baby
Matt Green gave a pretty good summary of this:
[https://twitter.com/matthew_d_green/status/99598925414360678...](https://twitter.com/matthew_d_green/status/995989254143606789)

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](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
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

~~~
sp332
Relevant comment from Werner Koch:
[https://twitter.com/FiloSottile/status/996011473112576000](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.

~~~
tptacek
This is shades of the curl maintainer rationalizing CURL_SSL_VERIFYHOST=1 not
doing any checking, because CURL_SSL_VERIFYHOST=2 does.

------
dimastopel
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...](https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-
vulnerabilities-require-you-take-action-now)

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
Werner Koch goes into further detail at the start of the gnupg-users thread @
[https://lists.gnupg.org/pipermail/gnupg-
users/2018-May/06031...](https://lists.gnupg.org/pipermail/gnupg-
users/2018-May/060315.html)

~~~
sambe
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?

~~~
klez
> not to use HTML emails, which seems unlikely in practice

In a context where pgp is used, which is not me receiving promotional material
or forwards from Grandma, why do you consider it unlikely that mail is to be
sent as plaintext and not as html?

~~~
deong
Almost every email client defaults to HTML. There are going to be people using
both encryption and HTML.

~~~
e12e
The idea that you can combine full hypertext and security is absurd. IMNHO
this is the most significant problem with email (and many "secure" messaging
stacks that allow "rich content"). Sure, it's possible to define a secure
subset of html (basically bold/italics/underline, tables and headers).

But everyone adds transclusion (in-line rendering of linked content, which
leaks data _and_ opens up the door to bugs), fonts (ie: programs), images
(historically not a great idea), and some even Javascript!

And that's not even all the muas that runs in the browser, and try to expose
some safe subset of itself to be used for rendering the mail body.

So, html Email is insecure, when contrasted with plain text email.

Using pgp as "code signing" for hypertext applications ("html emails") isn't
nearly enough.

Sadly, afaik there's no agreed "safe" rich text format for mail. Absurdly rtf
would probably be better than html mail.

Anyway, I don't see how anyone could expect html mail to be safe in the first
place.

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

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

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

~~~
tptacek
It strips the PGP MDC and then uses a malleability attack on CFB or CBC to
inject content, but it's not a crypto attack? You have a definition of "crypto
attack" that nobody in the field uses.

~~~
rocqua
To be fair, a very large part of this attack is not about PGP at all. That
part is about abusing email-client rendering of partly encrypted messages, and
abusing S/MIME to get message malleability again exploited via HTML.

~~~
tptacek
Again, this is like saying that BEAST isn't really about TLS, because you need
a particular combination of client features to exploit it. The two attacks are
almost exactly analogous in this respect. But PGP has a cheering section, and
TLS doesn't.

~~~
rocqua
I mean that the first attack (having A PGP encrypted middle of an email that
the client just expands to plaintext) and the attack on S/MIME have nothing to
do with PGP mistakes in PGP at all.

The gadget attack on PGP is completely an exploit against PGP, but this
publication also treats other attacks. At the very least, if you weigh this by
volume of text, they focus a lot on pure client mistakes (first attack) and
S/MIME (half of second attack).

------
Sir_Cmpwn
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
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
Yeah, mutt is safe

[https://pbs.twimg.com/media/DdJ_d_wWsAEclUs.jpg:large](https://pbs.twimg.com/media/DdJ_d_wWsAEclUs.jpg:large)

~~~
dmix
And the K-9 app seems safe which is the most popular way to use PGP on
Android.

~~~
e12e
If true, that's great news. There are plenty of decent cli/desktop clients
that make it easy to avoid html mail. Not so for Android, where apps seem
likely to wrap some rich content control in order to render text (as html).

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

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

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

~~~
Dylan16807
You should not be able to detach the signature when you're using an encryption
mode with known-plaintext attacks. If you're not going to make decryption
depend on having the original signature, _at least_ use an encryption mode
where any changes scramble the rest of the plaintext. Unauthenticated CBC is
not acceptable.

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

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

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

~~~
yrro
Forgive me but isn't GPGME the high level library that programs probably want
to use rather than dealing with gpg's protocol themselves?

~~~
lmm
GPGME is a library that automates the exec-ing and pipeing, with all the
issues that come with that (e.g. poor error reporting).

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

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

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

~~~
maxerickson
Both things are problems. The encryption system should definitely be
communicating that the message was tampered with...

~~~
jerf
Well, again, the encryption system will. Or at least it can. (Apparently you
can encrypt without signing? WTF use is that? But let's assume signatures are
used.) The MIME structure of email is the problem here. It isn't OpenPGP's
problem to solve, which we know because there is literally no way for them to
solve it. No conceivable (sensible[1]) update to OpenPGP could fix the
problem, so it can't be their responsibility.

[1]: I mean, yeah, they could ship something that hacks the Thunderbird
process and gets the rest of the email, but that's just crazy talk. Nothing
that has a sensible API that fits with what Thunderbird is doing now can solve
the problem.

~~~
tazjin
> Apparently you can encrypt without signing? WTF use is that?

Sending a message without identifying the author, for example.

~~~
spacenick88
Which can be achieved with authenticated encryption by generating a new key
and deleting it afterwards

~~~
dane-pgp
Is there a standard for this? It seems like if you tried to do it by hand, the
receiver's UI would present this in a scary/confusing way. I'm imagining
instead some sort of "Alan Smithee" User ID which the UI interprets as
"deliberately anonymous/disavowable".

------
FrantaH
"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](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.

------
mehrdadn
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?

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

~~~
e12e
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?

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

~~~
dbrgn
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)_

------
simias
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
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](https://twitter.com/seecurity/status/995964977461776385)

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

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

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

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

~~~
wodny
Not necessarily. Mail can be intercepted when transferred between MTAs which
seem to be often vulnerable to STARTTLS stripping due to a fallback mechanism.
See "Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery
Security"[1].

[1]:
[https://conferences.sigcomm.org/imc/2015/papers/p27.pdf](https://conferences.sigcomm.org/imc/2015/papers/p27.pdf)

------
fabian2k
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?

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

~~~
dewyatt
Also tag 20 is the newer AEAD method: [https://tools.ietf.org/html/draft-ietf-
openpgp-rfc4880bis-04...](https://tools.ietf.org/html/draft-ietf-openpgp-
rfc4880bis-04#page-60)

------
gepeto42
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?

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

~~~
gsnedders
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).

------
tptacek
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
> 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](https://twitter.com/robertjhansen/status/995977877375070209)

According to [https://lists.gnupg.org/pipermail/gnupg-
users/2018-May/06033...](https://lists.gnupg.org/pipermail/gnupg-
users/2018-May/060334.html), 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").

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

~~~
cyphar
I just tried it on my machine (I'm also using gpg 2.2.7) and I got
DECRYPTION_FAILED when I do the following:

    
    
        % gpg --version
        gpg (GnuPG) 2.2.7
        libgcrypt 1.8.2
        Copyright (C) 2018 Free Software Foundation, Inc.
        License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
        This is free software: you are free to change and redistribute it.
        There is NO WARRANTY, to the extent permitted by law.
    
        Home: /home/cyphar/.gnupg
        Supported algorithms:
        Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
        Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
                CAMELLIA128, CAMELLIA192, CAMELLIA256
        Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
        Compression: Uncompressed, ZIP, ZLIB, BZIP2
        % gpg --encrypt --disable-mdc input --output output
        % gpg --decrypt --status-fd 1 --output should_not_exist output | grep DECRYPTION_FAILED
        [GNUPG:] DECRYPTION_FAILED
        % echo $?
        2
        % diff -s input should_not_exist
        Files input and should_not_exist are identical
    

However (as you can see above), it looks like GPG outputs to the file when it
shouldn't (and Werner said that it doesn't so there's definitely a bug here).

------
ipioxu15
Also discussed here:
[https://news.ycombinator.com/item?id=17063109](https://news.ycombinator.com/item?id=17063109)

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

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

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

------
aleks_me2
I have read the statement on eff [https://www.eff.org/deeplinks/2018/05/not-
so-pretty-what-you...](https://www.eff.org/deeplinks/2018/05/not-so-pretty-
what-you-need-know-about-e-fail-and-pgp-flaw-0) 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/](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?

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

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

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

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

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

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

~~~
floatboth
> optional, so is not a useful mitigation here

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

~~~
AgentME
Other than anonymity, non-repudiation is a possibility. I may not want the
recipient of my messages to be able to undeniably prove what I said to them.
This case is important if I'm saying unflattering things about a mutual
friend, or my messages could be read as admitting a crime, etc.

(Though note that the vulnerability here still applies to signed messages too:
[https://efail.de/#will-signatures](https://efail.de/#will-signatures))

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

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

------
cromwellian
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?

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

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

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

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

------
kbumsik
> 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?

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

~~~
dane-pgp
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.

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

[https://mobile.twitter.com/ProtonMail/status/996006094605570...](https://mobile.twitter.com/ProtonMail/status/996006094605570048)

~~~
jwilk
Non-mobile link:

[https://twitter.com/ProtonMail/status/996006094605570048](https://twitter.com/ProtonMail/status/996006094605570048)

------
fouc
TIL: I should be using Mutt.

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

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

