Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 12 submissions in the queue.
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 #1  Original Submission #2 

 
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.
  • (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.
    Starting Score:    1  point
    Moderation   +3  
       Interesting=1, Informative=2, Total=3
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (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.

      --
      Revolver, or semi automatic modified to be fully automatic -- which is best for senior citizens in their porch swings?
  • (Score: 4, Informative) by takyon on Monday May 14 2018, @08:56AM (4 children)

    by takyon (881) <{takyon} {at} {soylentnews.org}> 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.)

      --
      Alternative für Deutschland
      • (Score: 2) by takyon on Monday May 14 2018, @11:53AM

        by takyon (881) <{takyon} {at} {soylentnews.org}> 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?