I can see how it would work against Apple Mail/iOS Mail since they load HTML and external elements by default.
I would be interested to see the attack working on a Thunderbird client with Enigmail installed and no other settings changes (like; loading external resources).
Thunderbird disables remote loading by default. It's vulnerable only if you take measures to override this, which is to say, you either:
1. Use movemail to receive email instead of IMAP or POP (there's an interesting vector to get your remote resources loaded by using movemail. If you read the code, you can probably guess it).
2. Enable remote loading for all senders by default.
3. Try to send an email with a sender you think will be whitelisted.
From the paper: "For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message."
This is bad news. Also, they claim/suggest that the following:
<link href="http://efail.de" rel="preconnect">
is a "bypass for remote content blocking" in Thunderbird, whatever that may mean exactly.
EDIT: Mozilla's docs at https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types say about preconnect: "Provides a hint to the browser suggesting that it open a connection to the linked web site in advance, without disclosing any private information or downloading any content, so that when the link is followed the linked content can be fetched more quickly." (emphasis mine). If that is really the spec and I understand it correctly and Thunderbird behaves differently, then that seems like a bug in Thunderbird.
Allowing preconnects when remote resource loading is disabled would be a serious security fail, so I hope that's not what Thunderbird is doing. Suppose I initiated a connection to long-unique-identifier.mysite.com? At minimum this could be used for tracking beacons, possibly even to exfiltrate data.
Since the exploit depends on sending manipulated emails, I think that 3. and 4. are pretty easy, since it'll look like the email is from a trusted sender (and encrypted)
This is the weird part. Sure, Outlook 2007 and Apple Mail are vulnerable, but if you are really parsing untrusted HTML with these clients you probably have more pressing problems (running arbitrary code, perhaps).
From a quick test it seems like a completely standard Thunderbird/Enigmail not only checks the error code from gpg, but also doesn't render HTML by default. There must be something more to this, unless something was fixed quite recently, in which case that would seem very relevant to the announcement.
It's not. The MDC-stripping attack on PGP is very well known --- it's obvious from the structure of the protocol. The paper you're citing uses it to build a direct plaintext recovery attack similar to a padding oracle. Today's paper uses ciphertext malleability to inject active content that exfiltrates the plaintext.
As far as I understand it, the earliest communication was 2017/11/24, which they addressed as it appeared that GnuPG wasn't vulnerable as it would fail with an error message when processing the exploit as it was known in November.
A few days later, they got an email asking for a phone call, which wasn't followed up upon--I'm not sure to what extent this is GnuPG's fault, whether this is a usual way of communicating a serious vulnerability. It would've been better if they called em back, definitely goes for both parties.
Then after a few months of silence, 2.5 weeks ago, they received another email with a different title that, according to Werner Koch, was too redacted to act upon:
On 2017-11-29 we got a short mail asking for a phone call. It might be
that I did not reply to that but in any case my office phone number is
easy to lookup. I did not get a phone call.
Since then we have not seen any more communication - not even about the
proposed coordinated public disclosure. Thus I closed this issue in
December and forgot about it.
On 2018-04-27 I received another paper via a Kmail developer which had a
different title than the one from November
*** DO NOT PUBLISH OR SHARE ON PUBLIC MAILING LISTS ***
Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels
and no author names etc. The GnuPG team discussed this but did not see
that any action was required. In particular because due to the
redaction we were not able to contact and help the developers of other
MUAs which might be affected.
I mean yeah, in theory, BOTH parties could have been better at communicating and following up on it. But both parties are probably very busy and this kind of "no you call me back" is the sort of thing that falls through if you have to make choices about what to spend limited time on. That's why there exists protocol and coordination to tell something is really serious/urgent.
It does seem to me that the security researchers were a bit too trigger-happy on the redacting of information, in particular unnecessarily so in private emails to the security folk they expected to act on the vulnerability.
It however confirms that the OpenPGP devs had no knowledge of an embargo, and thus didn't break any embargo. Sebastian Schinzel claimed they had to publish early because the embargo broke.
