Podcast: Efail Vulnerability and Its Impact on Encrypted Email
The Efail vulnerability has been in the news and has many people rushing to remove encryption from their email clients. The security vulnerability does impact S/MIME and PGP users, but only a subset. That means a lot of people are removing encryption from their email unnecessarily and putting themselves at risk. Atomicorp CEO Mike Shinn discusses what Efail is, how the exploit works and why the notification process was handled poorly. If you ever need email encryption, you should definitely listen to this episode.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.
Podcast Transcript: Efail Vulnerability and Its Impact on Encrypted Email
Bret Kinsella: [00:00:00] This is the Linux Security Podcast, Episode 8. Today we talk about the Efail vulnerability and the impact on encrypted messaging.
Bret Kinsella: [00:00:17] All right we’re back with Linux Security Podcast. And my guest today once again is Mike Shinn, CEO of Atomicorp. And today we’re going to talk about Efail or the Efail vulnerability. Mike, why don’t you tell the audience what this is about and why people are so spun up about it.
Mike Shinn: [00:00:34] So Efail is a vulnerability that came out really less than two weeks ago that was originally presented as some kind of fundamental vulnerability in the encryption that’s typically used to send emails. This thing was characterized in such a way that even the EFF, the Electronic Frontier Foundation, put out this warning saying everybody should effectively stop encrypting their emails. This vulnerability was characterized as some kind of systemic flaw in the way that really all emails are encrypted such that if you received an encrypted email someone would not only be able to read THAT e-mail but they would be able to read every encrypted email that you sent. So naturally this was something that registered pretty significantly with the cybersecurity community because as you can imagine cybersecurity people tend to use things like encrypted email more than normal people do. Where this became newsworthy, because we have vulnerabilities all the time, was that this vulnerability really wasn’t either as bad as it seemed and was also not really… what it seemed. So this was an interesting example of maybe people with the best of intentions trying to communicate a significant vulnerability and either not characterizing it in a way so that people could take appropriate actions or maybe they had you know maybe they were motivated to really amp this thing up but what it turned out was that this wasn’t actually a vulnerability in the cryptographic systems at all that are used to encrypt messages.
Mike Shinn: [00:02:32] These were actually vulnerabilities in a few email clients. So the original advice to stop encrypting your emails while well-intentioned and perhaps a reasonable thing to suggest based on the information that the EFF had at the time was not necessary for any user that wasn’t using one of these vulnerable email clients. And in fact it could have led to people operating in an even more risky manner. If you need to be able to encrypt your emails telling people to stop doing that it shouldn’t be something that we do without careful consideration for what the risks are associated with that. So Efail is ironically named vulnerability because the whole mechanism by which this vulnerability was reported was really a failure. It was mischaracterized… for many people myself included. It didn’t affect me at all. The email clients that I use weren’t vulnerable to this. So it’s really a cautionary tale for users that are trying to evaluate the efficacy of a vulnerability and to determine what a reasonable set of actions are to manage their risks that you can’t just take the advice of the people who are publishing a vulnerability even if their intentions are good. Maybe they’re mistaken. Maybe they don’t understand it. You know maybe they’re overreacting to something you really have to do your own homework.
Bret Kinsella: [00:04:09] Ok. So let’s talk about this for a second. So how much of email traffic is encrypted today?
Mike Shinn: [00:04:14] Probably very little. Right. The mechanisms to encrypt email are at least a quarter of a century old. Going back to the venerable PGP. It’s not been difficult to encrypt e-mails from a “does a tool exist and is it free?” perspective. A lot of email clients even have this capability built in. There’s another standard called S/MIME that’s basically built into every email client but very few people encrypt their e-mail. So this is also sort of an interesting vulnerability in and of itself because most emails aren’t encrypted anyway so you know how bad is it really if people can get to all of your emails if you’re if you’re not encrypting them. So it’s a vanishingly small number of people that encrypt their emails. But I would argue if you’re encrypting your emails I have a reason for it. You know it’s not something that you can accidentally do with your email software.
Bret Kinsella: [00:05:17] Right. There’s a lot of people out there who for whatever they do because they deal with sensitive information they could become a victim that they want to encrypt that communication because otherwise it’s just plain text.
Mike Shinn: [00:05:29] That’s right.
Bret Kinsella: [00:05:29] That people can essentially snoop on. So in this case though the vulnerability in PGP and SMIME, what was it? Was it the encryption keys? Was it something else? Header information?
Mike Shinn: [00:05:43] Really what it was it was a vulnerability in the implementation that the email clients had. So there is a way that you could tamper with an encrypted message and send that to a user. So you wouldn’t be able to read it but you could tamper with it and then cause the email client to do something that it shouldn’t. That’s basically the gist of the attack. The actual components that do the decryption, PGP, open PGP, GnuPG… whatever you want to call it…Gnu PG is really the big one. Already had a countermeasure for this many years ago. So if one of these messages came in that had been tampered with it would complain and say this is a bad thing. You shouldn’t continue. You should stop. And if your email client was properly handling exceptions. Right. Here’s this external piece of software or this external library that you’re using to decrypt the message and it’s telling you this is a bad thing, your e-mail client should say “Okeydokey, I’m not going to display it”. So some email clients would ignore the warnings errors… what have you from these libraries and we just go ahead and process this data. And that gave an adversary the ability to create really a back channel that allowed them to be able to see the content of that e-mail and potentially see the content of other encrypted e-mails.
Bret Kinsella: [00:07:16] Were there any known incidents where someone was actually using this?
Mike Shinn: [00:07:21] Nothing that was published at the time. I mean in retrospect certainly possible since one of the countermeasures that was built in to GPG was to something within the same family of vulnerabilities. And generally that’s driven by either somebody presenting a hypothetical case where this could be exploited or perhaps somebody wrote an exploit. But no, not this particular attack. Wasn’t presented in that and in that manner that this is being actively exploited although one could infer from from the EFFs well-intentioned response that maybe they felt that it was being exploited. Either way, really the core of the problem was that things that did not have vulnerabilities at all were being lumped into this. The vulnerability was if you’re running a particular email client, it has this vulnerability that should have been what was published.
Bret Kinsella: [00:08:27] But most of the e-mail kinds didn’t have that problem.
Mike Shinn: [00:08:30] That’s right.
Bret Kinsella: [00:08:30] And it should have kept encrypting. And is this where the whole social media buzz came around… you know… the CIA made them do it and they’re trying to get them not to encrypt conversation?
Mike Shinn: [00:08:40] Yeah there were some people that had troll-ish responses to this which was that this vulnerability was published because the CIA wanted to be able to read people’s emails. I mean that as you asked earlier vanishingly few people encrypt their e-mail anyway. So if the CIA wants to read your emails you’re probably not doing anything to stop them now. So you know this one I think got even more attention than typically over a characterized vulnerability would because you’re talking about something that it would be surprising for a cyber security person to not know what PGP and SMIME and to have not use them at some point in their life and maybe they use it now. So this was a highly unusual case of somebody saying “The sky is falling!” to a group of people who would be the best equipped people in the world to see through that.
Mike Shinn: [00:09:44] And that doesn’t always happen. A lot of vulnerabilities that are published really don’t get the level of scrutiny that they should. You know and this can cut both ways sometimes vendors will publish vulnerabilities and we’ll underplay the significance of a vulnerability. And it’s rare for a vendor to overstate the significance of the vulnerability. It is not un-rare for security professionals to overstate a vulnerability. It’s a running joke in the cyber security community that if you find a vulnerability you have to have a cool name and a logo and a website and a theme song and…
Bret Kinsella: [00:10:23] Which Efails does or oh you do not a theme song I don’t think that definitely have the logo.
Mike Shinn: [00:10:27] Not yet. Not yet. Yeah I mean you got to have you got shwag and T-shirts and everything to go with it right. I mean I get it. You know in this industry you become famous when you find a vulnerability. You don’t become famous if you figure out a way to protect people. So there are market forces that certainly push this along. And there are people with very good intentions that find vulnerabilities and want to provide that information in a way that helps people to make good decisions. The cautionary tale here is that sometimes that process breaks down. Things can be overexaggerated or maybe not communicated well. I’m not saying which one it was in this case because I can’t read their minds I don’t know what what drove them to this. But the vulnerability wasn’t really what the initial reports that characterized it as and several well-intentioned people put out some maybe not good advice to stop using cryptography.
Bret Kinsella: [00:11:23] So the bottom line is that you can still encrypt your e-mail, you can still encrypt your e-mails, the right type of clients actually address the vulnerability and have addressed the vulnerability for years. And if you’re going to roll out a vulnerability to the world, just make sure you’re being clear about what the scope of it is.
Mike Shinn: [00:11:43] Yeah don’t give bad advice. And you know we’ve got to be careful. We put vulnerabilities out that we also don’t start developing a habit of crying wolf. And eventually people will stop paying attention to these things. There’s enough vulnerabilities coming out every week. We don’t need to exaggerate them. We just need to be calm and rational and provide the facts. You know maybe you don’t need a cool name for it. That’s fine if you want to come up with one but just get the facts right. Don’t get people all spun up and in this particular case for the platforms that weren’t affected by this vulnerability the advice would have in fact made things worse.
Bret Kinsella: [00:12:28] That’s right. That’s right. Well, thank you very much Mike. It was great getting a summary on that and hopefully everyone out there is a little bit better informed about Efail and the limitations of the vulnerability.
Atomicorp provides unified workload security for cloud, data center or hybrid platforms. Built on OSSEC, the World’s Leading Open Source Server Protection Platform. See our products.