From the gaping maw of the infosec Twitterverse comes horrifying news. PGP is broken. How? We don’t know. When will there be any information on this vulnerability? Tomorrow. It’s the most important infosec story of the week, and it’s only Monday. Of course, this vulnerability already has a name. Everyone else is calling it eFail, but I’m calling it Fear, Uncertainty, and Doubt.
Update: eFail site and paper now available. This was released ahead of Tuesday’s planned announcement when the news broke ahead of a press embargo.
Update 2: The report mentions two attacks. The Direct Exfiltration attack wraps the body of a PGP-encrypted email around an image tag. If a mail client automatically decrypts this email, the result will be a request to a URL containing the plaintext of the encrypted email. The second attack only works one-third of the time. Mitigation strategies are to not decrypt email in a client, disable HTML rendering, and in time, update the OpenPGP and S/MIME standards. This is not the end of PGP, it’s a vulnerability warranting attention from those with a very specific use case.
Update 3: Hackaday has published an in-depth explanation of how eFail works which details the scope of the vulnerability.
[Sebastian Schinzel] announced on Twitter today he will be announcing a critical vulnerability in PGP/GPG and S/MIME email encryption. This vulnerability may reveal the plaintext of encrypted emails. There are currently no fixes — but there’s no proof of concept, or any actual publication of this exploit either. The only thing that’s certain: somebody on Twitter said encrypted email is broken.
The EFF has chimed in on this exploit and advises everyone to immediately disable and uninstall tools that automatically decrypt PGP-encrypted email. It also looks like the EFF came up with a great little logo for eFail as well so kudos on that.
While there are no details whatsoever concerning eFail aside from a recommendation to not use PGP, a few members of the community have seen a pre-press of the eFail paper. [Werner Koch] of GnuPG says eFail is simply using HTML as a back channel. If this is true, PGP is still safe; you just shouldn’t use HTML emails. If you really need to read HTML emails, use a proper MIME parser and disallow access to external links. It should be noted that HTML in email is already an attack vector and has been for decades. You don’t need to bring PGP into this.
Should you worry about a vulnerability in PGP and email encryption? Literally no one knows. European security researchers are working on a publication release right now, but other experts in the field who have seen the paper think it’s not a big deal. There is no consensus from experts in the field, and there is no paper available right now. That last point will change in a few hours, but for now eFail just stands for Fear, Uncertainty, and Doubt.
Looks like there’s more detail here: https://efail.de/
Damn you’re quick.
https://arstechnica.com/information-technology/2018/05/decade-old-efail-attack-can-decrypt-previously-obtained-encrypted-e-mails/
This was out like 8 hours ago. Almost the first comment on HN. Surprised this post didn’t have it
PGP and S/MIME are ok.
The way they are used in the MUAs is broken.
PGP is fine. PGP when used by browsers that intermix decrypted pgp text with html is what’s causing the problem. If you’re reading encrypted email in an html-enabled email browser you’re doing it wrong!
Correct. This is not PGP or MIME being broken, or Email not secure anymore… this is an order of operations issue and how mail clients handle messages… download everything first, then decrypt would fix this.
S/MIME*… also, the attacker needs to have intercepted the encrypted message first.
Now all we need is to find people that use PGP.
Quote of the day ????????
You know, there might even be a website that can tell us that.
I understand what’s going on with the s/mime and email clients, but can someone explain the part about CBC/CFB gadgets? That seems potentially more important but articles gloss over it
Seems my decision to stick to using plain-text emails when everyone else in my company uses HTML is well and truly vindicated.
Then again, I’m also the only person who has OpenPGP set up.
Only peasants use encrypted email (PGP, etc). The 21st century has arrived folks: If you need to communicate securely, use Signal. If having Signal on your phone will arouse suspicion, use WhatsApp.
-1
An advantage of pgp over signal is that it you can post your public key so that others can contact you without prior interaction, and without disclosing your phone number. Also, you can sign messages to prove its from you. This can be useful if you want to maintain an identity across various websites, while having the option to tie your real name to the public key or remaining anonymous.
Threat modelling.
It’s a thing.
email is a very valid way to really annoy salespersons
I don’t immediately trust signal. (or ‘telegram’ for that matter, while we mention often trusted software)
US-based and also: Funded by… “The Open Technology Fund (OTF) is a U.S. Government funded program “..
Although on the topic of the main guy:
“Marlinspike says that when flying within the United States he is unable to print his own boarding pass, is required to have airline ticketing agents make a phone call in order to issue one, and is subjected to secondary screening at TSA security checkpoints.
While entering the United States via a flight from the Dominican Republic in 2010, Marlinspike was detained for five hours; federal agents requested his passwords, and all his electronic devices were confiscated and then returned”
But I’ve heard that kind of thing before, from people who turned out to have embraced ‘the man’ with some enthusiasm.
And it’s of course exactly what they would put on Wikipedia to make people trust him, naïve people mostly.
I know of at least one company, which I will not name, that tracked all emails automatically by adding a unique URL to a single pixel in all html emails. They added them to every email sent by every employee at the company. They had an department dedicated to studying the collected metadata of interactions of internal employees, external companies and news organizations globally. Apparently it was implemented to detect and track leaked information. The single pixel was hosted on an external website, it was not w3.org, but something that looked just as innocuous when embedded in html.
This is common amongst so many emails that i recieve and thankfully i practice safe computing so it is not a problem for me. Safe computing for email:
1. no external content
2. force plaintext, no html.
3 vet and scan all attachments.
If the information in your email can not stand on its own then it is not important to me. If you need to use external content to make your point then your point is not important to me. The problem lies in how people use email and not in any of the encryption at all, this is a bullshit vulnerability because if companies like microsoft, apple and google didnt sully email with html rendering then this wouldnt be a problem but then they wouldnt be able to try and sell us stuff with flashy ads or track us with invisible pixels.
Emails and advertisements are the two biggest threat vectors for the average person, a little bit of prevention nullifies this risk easily.
Since 90%+ of email is now made on webpages with services like gmail it has become very hard to ban HTML.
I used to do it 100% in the past, but now many emails becomes completely unreadable or unable to do required steps when you do. Especially commercial email of course like order confirmations and stuff like that.
And email from official places (gov and local and such) also tends to be annoyingly problematic if you try to stop HTML.
Mind you, Instead of blocking HTML for PGP use you can of course just exchange the PGP traffic in plain text and decrypt that outside the email client. It’s the integration that is and will remain an issue I expect, even if this is patched, it will have unreported flaws still I predict.
Classic example of bullshit-disclosure. Bug name, logo and website all up before anything is publicly disclosed… about a bug that was mostly known more than a decade ago, is not in the software (pgp/gnupg) that it purports to relate to, and which has already been fixed in most places (graphical MUAs) to which it actually pertains.
choo choo all aboard the hype train.
Might be also be an attempt to discourage people from using PGP.
Even when OpenPGP seems to use very short keys ‘for some reason’. and might not be a problem for the kind of people that want to read the messages.
Timing is all…
Just a week ago I scolded one activist group sending me a newsletter “Sadly, your mail client doesn’t support HTML”.
Of course I know what’s going on, that this is a multipart/alternative MIME, that the text part (the only one my MUA shows me by default) has this “too bad so sad” text, and that I could use a HTML viewer to see the HTML version (my preferred being html2text, mind you).
But I was pissed off at this nudging people into more insecure alternatives, especially in this patronizing tone. Not even done by the activist group itself, but outsourced to some mass-mailing infrastructure (possibly free software!).
I’m having a hard time to unravel all those layers upon layers of stuff, where evil sneaks in silently. I’d like some ideas on how to do better. I still am not sure I could convey my point to them:
– you folks are awesome
– your software is doing things on your behalf you sure wouldn’t approve of
– but you don’t even understand what it is doing.
Ideas?
So instead of disabling HTML you can also just use the standard not allowing external items settings I assume?
Not so handy for the billions using web-based readers of course.
What scares me most are not the super elite exploits, but the ones that are super obvious in retrospect.
They’re the kind of fuckups that *ought* to have caught, but were not. That’s scary. When it (fictitious example) takes an obscure quirk in the memory allocator combined with a kernel bug to execute a ROP payload, nobody’s expected to realise that was possible. Finding and exploiting that sort of bug requires an immense amount of domain knowledge and skill. When all it takes is a trivially crafted malicious email to cause the client to automatically decrypt and leak data via a requested URL, it makes you wonder how people missed that.
And I’m not laying any blame, computer security is pretty much impossible for humans to achieve. My code is probably as full of obvious bugs as most average programmers. Nor am I saying I would have discovered this – obvious vulns are only obvious in retrospect!
Really though, we need to start treating plaintexts as like, the inverse of untrusted input. Data constructed from the decrypted plaintext should not flow to untrusted or untrustable components. It’s a convenience tradeoff though.
Look! This hacker is using a balaclava alternative. Next HaD article on which fishing rod is best for getting peoples data
This is a special hacker though, one who is also a ‘civil servant’ in that he will work for a government, because they are the only ones wanting to read your PGP messages of course.
which is why (one of the many reasons) my email client can ONLY talk to my email server. All other ports and ip address are forbidden.
Why anyone lets the emails they read dial back to everywhere whenever they open it is beyond me…