Hacker News Reader

Comment by AnaniasAnanas | Hacker News Reader

To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for helping the spread of the FUD without even consulting the GPG people.

[1]: https://twitter.com/seecurity/status/995936859980222464

View on HN

> (in fact I am not aware of any client that is vulnerable to this)

> First, the direct exfiltration attack abuses vulnerabilities in Apple Mail, iOS Mail and Mozilla Thunderbird...

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).

According to this table Thunderbird is vulnerable: https://twitter.com/matthew_d_green/status/99599862678571417...

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.

4. Convince the user to click on a link.

> Thunderbird disables remote loading by default.

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)

The encrypted messages will not be signed, unless the trusted sender is also the attacker or their key is compromised.

Does Thunderbird verify that the message is signed before displaying images from a whitelisted sender?

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.

Also, the second attack seems quite similar to https://eprint.iacr.org/2005/033.pdf.

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.

Also relevant https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...

This seems to contradict the earlier claim that "the GnuPG team was not contacted by the researchers".

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.

Reply on news.ycombinator.com