Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

efail.de

Post reply on HN
Print view View original

91–100 of 306 posts

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#91

Post by tlogan »

noguespi wrote: post #58

A lot of buzz for a not so critical vulnerability. Well it is critical but very hard to exploit because : 1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client. Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content. By the way I hate this kind of "buzz" disclosure. Just disclose full…

The problem is that decrypting software will do: "Here's the message and some 'extra stuff'".

Now, this 'extra stuff' might not be HTML, might be something which might trigger something else. I really do not know but some smart guy might figure out how to exploit that part. Or might not.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#92

Post by dbrgn »

egeozcan wrote: post #5

If I understood correctly, I think this can be prevented by a single configuration change: "Do not automatically load inline content" but this is just speculation. I'd disable HTML rendering completely until everything becomes clearer.

In the explanation of Table 5 in the paper (page 21), there's a list of attack vectors with the title "HTML attributes (bypasses for remote content blocking)". So apparently some of these attributes do bypass the inline content blocking on some mail clients, unless I read that wrong. It's important to note that most e-mail clients will use a webview to render e-mail. Blocking all kinds of remote content requires the developers to be really careful, and also probably violates the HTML spec.

I tried to replicate the Thunderbird attack vector (H₂), but at least in the current version (52.7.0) it seems that the URL is not requested. Maybe that has been fixed in the meantime but was present in an older version?

Disabling HTML rendering for now is probably the safest choice. There's not much that can go wrong when rendering a plaintext e-mail.

(Edit: Added a sentence regarding webviews)

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#93

Post by jakobegger »

segmondy wrote: post #89
baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

Just curious, why didn't you submit a patch?

Not the OP, but finding a vulnerability is a very different skill compared to fixing a vulnerability.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#94

Post by dewyatt »

AnaniasAnanas wrote: post #36
fabian2k wrote: post #20

From what I've read, I thought that in modern cryptographic methods you always authenticate and encrypt, in part to avoid attacks like this where an attacker can modify the encrypted message in some way. Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?

OpenPGP does have a way to authenticate the messages, see https://tools.ietf.org/html/rfc4880#section-5.13 .

Also tag 20 is the newer AEAD method: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04...

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#95

Post by jakobegger »

jcranmer wrote: post #85
baby wrote: post #73

Earlier quoted context omitted.

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…

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)

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#96

Post by jerf »

maxerickson wrote: post #72
jerf wrote: post #68

Earlier quoted context omitted.

I disagree. The encryption system should not know about HTML, and these messages are "BAD MESSAGE"s even if they are unencrypted. That clearly points at the mail client, not the encryption layer.

Both things are problems. The encryption system should definitely be communicating that the message was tampered with...

Well, again, the encryption system will. Or at least it can. (Apparently you can encrypt without signing? WTF use is that? But let's assume signatures are used.) The MIME structure of email is the problem here. It isn't OpenPGP's problem to solve, which we know because there is literally no way for them to solve it. No conceivable (sensible[1]) update to OpenPGP could fix the problem, so it can't be their responsibility.

[1]: I mean, yeah, they could ship something that hacks the Thunderbird process and gets the rest of the email, but that's just crazy talk. Nothing that has a sensible API that fits with what Thunderbird is doing now can solve the problem.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#97

Post by gepeto42 »

Encryption plugins on top of other mail clients has always been a recipe for disaster.

That being said, why would EFF tell people to completely uninstall it? When I hear that, I think "There is a crazy, in the wild, no user interaction needed remote code execution vulnerability". If someone had a use for PGP/GPG email (assuming they understand the threat model and the metadata that is not encrypted), surely they're better off with a buggy version that with pure cleartext?

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#98

Post by klez »

sambe wrote: post #78
patoh wrote: post #3

Earlier quoted context omitted.

Werner Koch goes into further detail at the start of the gnupg-users thread @ https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...

I'm reading this message with little context but it doesn't strike me as having reasons not to be worried. The two suggestions are: a) not to use HTML emails, which seems unlikely in practice; b) to use an obscure-sounding mode which has been implemented in such a way as to depend on the MUA doing multiple things correctly after the GPG code runs. What am I missing here? Is the latter mode on by default and MUA are w…

> not to use HTML emails, which seems unlikely in practice

In a context where pgp is used, which is not me receiving promotional material or forwards from Grandma, why do you consider it unlikely that mail is to be sent as plaintext and not as html?

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#99

Post by tom_mellior »

jcranmer wrote: post #85
baby wrote: post #73

Earlier quoted context omitted.

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…

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

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#100

Post by tazjin »

jerf wrote: post #96
maxerickson wrote: post #72

Earlier quoted context omitted.

Both things are problems. The encryption system should definitely be communicating that the message was tampered with...

Well, again, the encryption system will. Or at least it can. (Apparently you can encrypt without signing? WTF use is that? But let's assume signatures are used.) The MIME structure of email is the problem here. It isn't OpenPGP's problem to solve, which we know because there is literally no way for them to solve it. No conceivable (sensible[1]) update to OpenPGP could fix the problem, so it can't be their responsibil…

> Apparently you can encrypt without signing? WTF use is that?

Sending a message without identifying the author, for example.

Post reply on HN