cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
saeedakh
Viewer

Vulnerabilities found in PGP-encrypted emails

A group of European security researchers has released a warning about a set of vulnerabilities affecting users of PGP and S/MIME. These vulnerabilities pose an immediate risk to those using these tools for email communication, including the potential exposure of the contents of past messages.

A group of European security researchers has released a warning about a set of vulnerabilities affecting users of PGP and S/MIME. The Electronic Frontier Foundation (EFF) says it 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.

 

Users should refer to these guides on how to temporarily disable PGPplug-ins in:

Thunderbird with Enigmail

Apple Mail with GPGTools

Outlook with Gpg4win

EFF notes that these steps are intended as a temporary, conservative stopgap until the immediate risk of the exploit has passed and been mitigated against by the wider community.

6 Replies
Baechle
Advocate I

Saeed (@saeedakh),

 

I read the Twitter link in your message, and the original article that it referenced from the EFF.  The updated EFF article with the link to the research paper is here:

https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you-need-know-about-e-fail-and-pgp-flaw-0 

 

 

I'm a little confused about this announcement and the way that it is constructed.  The only two good mitigation actions that I saw in either piece was to (a) immediately move to another secure channel (I won't repeat the recommendation because I do not want to support the use of a particular application before I research it myself); or (b) use out-of-band PGP decryption rather than a plugin to your email client.

 

It seems to be more of the same Chicken Little claims that PGP is dead.  Instead, it appears to be more of a combination of bad HTML parsing in the email client itself, and a failure of the client to block unsigned PGP and S/MIME messages or those where the signature is invalid.

 

I don't understand how not using PGP software to encrypt/decrypt messages solves the issue.  It seems like the only outcome this would have is preventing me from reading my own email.  The real problem is with the client, so moving to an out-of-band PGP encryption/decryption tool should fix that.

 

The way the release is written, aside from the very quick mention of moving to an alternate secure channel, makes it seem like moving to clear text email is the rational choice over continuing to use a slightly broken PGP & S/MIME system.  It must be REALLY broken for that to make sense.  Like, this PGP vulnerability must be the key to time travel or something and as long as it exists on my computer, they can prevent my grandparents from being born...?  But the articles don't indicate that.

 

Anyone getting a different vibe here?

 

Eric B.

denbesten
Community Champion

There is a paper about the exploit.  Basically, if someone is in possession of an an encrypted email sent to or by you, they can potentially send you a normal looking email, including the encrypted message as a  hidden mime "attachment".  When you open the normal email, the encrypted attachment will be silently decrypted and posted to the bad actor's web server.  Figure 1 at the top of page 4 has a nice outline example.

 

There are a bunch of mitigating factors:

  1. The bad actor needs to be in possession of an encrypted message.
  2. You need to automatically unencrypt messages.
  3. Your email client needs to be susceptible to backchannels (e.g. "automatically load images").

A list of tested clients can be found on page 20.

 

Caute_cautim
Community Champion

Another perspective from Dark Reading: 

 

https://www.darkreading.com/endpoint/privacy/efail-email-encryption-flaw-research-stirs-debate/d/d-i...

 

Looks like practical advice

 

 

Baechle
Advocate I


@Caute_cautimwrote:

Another perspective from Dark Reading: 

 

https://www.darkreading.com/endpoint/privacy/efail-email-encryption-flaw-research-stirs-debate/d/d-i...

 

Looks like practical advice

 

 


Good find.  I particularly like one of the comments, that someone at EFF started shouting "Fire" when they were told the researchers found some matches...

JoePete
Advocate I

If I read/understand the issue properly, one of the keys (no pun) to exploiting the vulnerability is crafting an HTML-based email to someone with the appropriate private key (i.e. the original intended recipient) whereby that email must do two things:

  1. Hide the encrypted message that the attacker wants decrypted
  2. Through the use of some backchannel (e.g. placing using the to be decrypted email as the src of an HTML img tag), the content will be decrypted and sent back to the attacker (as a requested resource from his/her/their server)

Yes, it is a vulnerability - more with the email clients than the PGP, etc., but I find it very hard to believe that someone security-aware enough to be using PGP to encrypt emails would also be setting his or her mail client to read HTML email and/or to otherwise obfuscate content. The bottom line this gets back to is age-old axiom: Never, ever, read HTML email. And of course the corollary: Never, ever send HTML email. It is a rude and hazardous as sneezing in someone's face. So yes, there is a risk here, but it is a bit like telling people who text and drive that that they should disable audio notifications because the sound may distract them. That risk is only enabled by a larger risk they are taking and posing.

denbesten
Community Champion


@JoePete wrote:

 

Yes, it is a vulnerability - more with the email clients than the PGP, etc., 


In my estimation, the primary flaw efail exploits is the that most email clients do not validate that HTML is balanced (all tags are closed and tag-pairs are matched) before processing the next mime part.  Had that been done, it would not have been possible to embed it within an "<img src=..." tag.