#eFail is #reFail

[Joseph Sinclair]

The EFF recommendation is primarily an abundance of caution for the community who use PGP for mail as many such users are at risk of serious and targeted attack.
PGP being enabled won't open a threat vector for some other attack.
Having it enabled in email may, however, allow a targeted attack to expose the decrypted content of those emails; so for now (if you have very high-value encrypted emails) it may be better to export PGP email and decrypt at the command line for reading in a text editor.

TL;DR
Overall this is a class of attacks that could expose the plain text of emails encrypted with S/MIME or PGP, but requires enough effort and skill that it's mostly an issue for individuals who are using PGP or S/MIME to defend against serious threats, such as criminal organizations or state actors, and have emails containing sufficient value to justify the level of effort involved.
All users should disable HTML in email by default, regardless, as that is a major attack vector that has no known mitigation (and likely never will), HTML may be enabled for individual (unencrypted) messages as needed.  Encrypted email should, of course, never be anything other than plain text (with separately encrypted attachments if needed).

Below is my (admittedly limited) full assessment for those who might be interested.

The vulnerabilities requires two major factors:
1) The attacker must have the original encrypted message (the ciphertext) still encrypted.  These are most concerning as Man-in-the-Middle attacks.
2) The client must (generally) have HTML email supported and enabled (note, HTML isn't the only backchannel available, but it's the most likely and by far the easiest to implement).

Note that all of these techniques export some amount of the decrypted data, but not a massive amount.  Somewhere between 4 and 200 bytes.  They can be repeated, however, within a final multipart MIME email to obtain the full text.

How it works, in short form:
If you have HTML enabled on view, the attacker can send you a message in HTML format with the ciphertext buried within the HTML (e.g. inside the href attribute of a img tag), and use url packing (putting tracking text in a URL after the resource path) to send that text to a server.  The client will happily decrypt the contents, then attempt to access the url, sending the decrypted data to the server as part of the request.
If you have one of the HTML email clients (e.g. most webmail clients) that allow script within the email, then a script could easily send the *entire* decrypted content to the server, and then display *only* that to the user; successfully hiding its tracks while obtaining the full decrypted message.  Webmail clients should probably never be used with PGP or S/MIME.

What the attacker does is grab the encrypted message, modify it to take advantage of one of the discussed techniques, and then forward it on to the intended recipient.
In the simplest case, the attacker just wraps the content in properly structured HTML (ideally with script) and adjusts the MIME structure, then send it on.  If HTML is enabled, this can be enough.
If a more advanced approach is required (and script isn't available), then the data can be restructured in several ways using flaws in specific block encryption modes (specifically CBC and CFB) to obtain small amounts of data in each MIME part; repeating the attack enough times to get most or all of the data (up to around 500 MIME parts).  The message looks funny, and might be suspicious, but it still has a decent chance of working.
With even more effort, a non-HTML backchannel might be used, something like MIME external data blocks and DNS sniffing, or PGP key lookups, but the amount of data obtained in this way will be quite limited.

GPG includes certain mechanisms to prevent the more difficult attacks against the OpenPGP specification, although it cannot do much about a leaky client.  Not all clients enable those features or respond to reported security issues properly, however, so while GPG is (or can be) secure, its use in email may not be, depending on the client.
Some mail gateways that apply encryption at the gateway are vulnerable, although most can be configured to be secure, and some are secure in the default configuration (details for these are not provided, of course).

On 2018-05-14 01:58 PM, Herminio Hernandez, Jr. wrote:
> So this why the EFF is recommending this
> https://www.eff.org/deeplinks/2018/05/disabling-pgp-thunderbird-enigmail
> 
> On Mon, May 14, 2018 at 1:24 PM, der.hans <PLUGd at lufthans.com> wrote:
> 
>> moin moin,
>>
>> lots of news about "new" PGP and S/MIME handling security issues.
>>
>> Considering GnuPG addressed it 15 years ago, it doesn't seem to be new :)
>>
>> Also, email clients automatically displaying remote content has never
>> been safe.
>>
>> Summary seems to be:
>>
>> 1. Using text mail rather than html mail mitigates one of the disclosed
>> issues.
>>
>> 2. Disabling old ciphers or having a mail client that properly handles
>> decryption warnings and/or sanitizes messages will work for the other.
>>
>> See mailpile's response for the latter.
>>
>> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
>>
>> https://www.mailpile.is/blog/2018-05-14_PGP_Security_Alert.html
>>
>> One good thing to come out of this is that I now know about mailpile :)
>>
>> ciao,
>>
>> der.hans
>> --
>> #  https://www.LuftHans.com   https://www.PhxLinux.org
>> #  Eternal vigilance is the price of liberty. -- Thomas Jefferson
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> 
> 
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20180514/6c27e464/attachment.sig>