Podcast: Meltdown and Spectre Vulnerabilities and Countermeasures Explained
It is not an overstatement to say that the Meltdown and Spectre vulnerabilities were a surprise to the security and microprocessor industries. Chip-level vulnerabilities this severe are rare. Part of the issue stemmed from the fact that the vulnerabilities were created by engineering choices designed to improve microprocessor speed. The engineers had simply not contemplated how hackers could exploit these “features” and security researchers rarely look into chip level design for vulnerabilities.
Meltdown and Spectre Impact
The result? Meltdown and Spectre vulnerabilities were open for a long time and impacted just about every mobile device in circulation. And, because they involved privileged access at the microprocessor level, no security tool would ever have identified successful attacks. We may never know if the vulnerabilities were exploited or what damage may have been done. Meltdown and Spectre have largely been closed, but there was a performance hit in terms of microprocessor speed and a lot of effort in updating Linux OS images.
Get the Lowdown on Meltdown from Mike Shinn
Atomicorp’s Mike Shinn has in-depth knowledge of the incident and breaks down the “flaws” and countermeasures in the most recent episode of the Linux Security Podcast.
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: Meltdown and Spectre Vulnerabilities and Countermeasures Explained
Bret Kinsella: [00:00:00] This is Episode 3 of the Linux Security Podcast. Today’s topics the Meltdown and Spectre vulnerabilities.
Bret Kinsella: [00:00:18] Welcome back to the Linux Security Podcast. Today we’ve a very special topic to talk about something that’s been in the news a lot this year Meltdown. And we’re going to talk about both the Meltdown and the Spectre vulnerabilities. Mike Shinn, as always is going to join us today and he’s going to give us the lowdown on why this matters and why it’s so darn complicated. Mike thanks.
Mike Shinn: [00:00:39] Yeah, my pleasure.
Bret Kinsella: [00:00:41] So tell us about it.
Mike Shinn: [00:00:42] So Meltdown and Spectre has been in the news quite a bit. They deal with what some people refer to as flaws in most of the microprocessors that we use certainly on the Intel and Apple platforms. Really, in some cases it may be equally fair to say that these are features of the way that these processors work. They are… effectively… these vulnerabilities are a side effect of things that microprocessor engineers invented to cause the microprocessors to run faster in some cases or people perform things faster. So without getting too technical, the two different vulnerabilities are similar in the sense that largely boiled down to someone is able to exploit it, if they can cause code to execute on your computer which basically means every single mobile device is affected by this because simply going to a web page can give an adversary an opportunity to execute code on your system… javascript for example. Or, you could just go to a website and then an add this plane that includes the code to be able to exploit it.
Mike Shinn: [00:02:05] So the two vulnerabilities are similar in the sense that they stem from design choices in the way of these microprocessors are built. They’re different in terms of the way that they are exploited. So meltdown is a privilege execution… or escalation attack I should say… which works by being able to trick the microprocessor into revealing information that it shouldn’t to the user. So it’s a way of getting the microprocessor to show you information that you’re not allowed to see. And Spectre is a way of being able to trick the system into executing code that it shouldn’t be able to do. So Meltdown is worse in the sense that from a theft of information perspective because Meltdown can affect the entire system. So Meltdown can allow you to get to any information that the microprocessor has. Spectre allows a bad guy to do things as the user that you are. In other words if you’re on a multi-user system Spectre doesn’t give the adversary the ability to get to data that only another user can see.
Mike Shinn: [00:03:29] So on first glance it may seem that Spectre isn’t really as big of a deal but they both affect different platforms differently. Meltdown is a really big deal for servers, cloud based environments, virtualization environments because what it means is that any user in that particular environment can see all of the information, data, memory that’s occurring across every single solitary user, container or virtual machine on that entire system. So that’s kind of a big deal. On a mobile platform, that’s not nearly as big of a deal because you typically have one user on that platform who can see and access everything. Spectre allows someone to kind of do a similar thing through your browser. So it’s a way of tricking the system into executing code and then it gives them the ability to look at other things that are occurring on your system.
Mike Shinn: [00:04:33] In this the primary attack vector for that is really a browser because that’s one of those few environments where we are executing somebody else’s code. Nearly every web page to go to his can be executing code. Meltdown is a different story. You need to be able to get code to execute on the system which tends to be a little bit harder to do on a server servers are typically not running things like browsers. But that doesn’t mean that you couldn’t get code on and in a cloud based environment it’s trivial right. You just log into your cloud based whatever that shared with you know 20 other people and you can now upload code and to be able to see what’s going on. So the countermeasures for this basically involve… Meltdown is a little easier to defend against Spectre. Meltdown then effectively has to put things in place to ensure that you can’t get to a memory that you’re not supposed to get to. And because this particular vulnerability exists because of design choices to try and help things speed up there, there can be some degree of performance degradation as a result of these countermeasures. That said microprocessors are pretty darn fast these days so effectively for most people they probably won’t notice it. Spectre is much harder to defend against because each of the individual applications have to be able to defend against this attack. Spectre’s not something that you can easily defend against at the system level. This is something where the applications themselves have to have countermeasures in place to be able to defend against spectrum.
Bret Kinsella: [00:06:07] So for Meltdown then, you talk about like a system protection. Where are you doing this you doing as the OS, the kernel? How are you getting to the microprocessor layer or shielding the microprocessor from these attacks?
Mike Shinn: [00:06:23] Yeah. So that the absolute best place to do this right would be the hardware. Right. You’d modify the hardware but that’s a non-trivial thing.
Bret Kinsella: [00:06:32] Well new hardware is coming out they just have this problem but there’s a refresh cycle.
Mike Shinn: [00:06:35] Isn’t that awesome right. I mean that’s just that’s just great for Intel and in any of the other vendors affected by that.
Bret Kinsella: [00:06:42] It’s how they’re shortening… it’s a refresh cycles have been growing three to five years and now they’re gonna bring them right down.
Mike Shinn: [00:06:49] This is probably gonna get written up in business schools as a case study of that site and planned obsolescence at this point. Right. It’s like planned vulnerability.
Bret Kinsella: [00:06:59] Okay so we’re just we’re joking a little bit.
Mike Shinn: [00:07:00] To some extent. I doubt very seriously that anybody did that. But I wouldn’t… I would be disappointed if this wasn’t discussed at least in some way and in a business class maybe as this is not something you should do.
Bret Kinsella: [00:07:16] Okay. So we have a lot of systems out there that are not going to be replaced next year or two years tomorrow. And so how do we protect against it with existing systems that have this persistent vulnerability?
Mike Shinn: [00:07:30] So where we have to start is we have to say what can we change on the systems and we can make changes to the operating system. Typically on these systems assuming that there are there’s a vendor out they’re still making updates for it. So on an older legacy system they may not be possible to fix this. That of course assumes that the older legacy system has this vulnerability. I will preface this by saying that this is going to put this in quotes a relatively modern vulnerability. Spoken as someone who has done a lot of work over the last few decades with legacy systems… there are legacy systems out there that are more than 30 years old that are not affected by this because their microprocessors don’t have this enhancement that creates this vulnerability. But for the rest of us, any reasonably modern piece of technology that’s out there the best place that a typical user can experience effects if they’re not going to replace the hardware is in the operating system. And that means down at the kernel level.
Mike Shinn: [00:08:37] That means that for Meltdown, the way that the system is managing its memory has to be significantly altered which you really can only do down at the kernel level. For Specter, the best place to do this is in the applications that have the attack surface like a browser that can be used to exploit this particular vulnerability. Now there may be things in some cases that can be done down on the micro code level. Particular microprocessors but not always. Some of those fixes have been problematic. So the practical reality is for most platforms this issue is being resolved within the kernel which sits below the operating system for Meltdown at least in the way that the system is managing its memory and not trusting users attempts to be able to access memory that it should prospector. It’s happening within the browser. So Firefox, Chrome, Edge those are things that the developers can do within those applications to harden them and immunize them.
Bret Kinsella: [00:09:44] Yeah, so for Specter then we’re looking we’re relying on our browser providers to push out updates that prevent that type of exploit that Spectre is executing in the Meltdown instance what we’re asking is Linux or the people build Linux OS is to do the update. We’re asking Microsoft to do the update. Correct.
Mike Shinn: [00:10:08] Right. That’s right. Yeah. All of the major operating system vendors… where this becomes problematic is when you start dealing with what I called derivative products or sometimes this category includes Internet of Things. So all of these little devices that are out there these days that are some derivative of Linux or BSD or maybe Windows Embedded and I shouldn’t say little things. Right. These may be big things too. These might be C.T. scanners or MRI scanners that are running commercial, general purpose operating systems on them as well. And so for consumer devices like phones and laptops and so on for any of the currently supported operating systems that are out there, all of the vendors have put out patches for these so the iPhones and the Androids and the Macs and you know Windows laptops and so on. As long as the operating system is still supported there’s a patch out there for the stuff that’s not been well. Addressed or all of the things that are out there that are running in many cases the same operating systems that we have running on our laptops and workstations and maybe even on our phones are not necessarily being well served. And it’s very challenging for an organization to know if those devices are adequately fixed because a may not be possible for them to teste it. You know the vendor maybe not totally forthcoming about it or in some cases the user may be completely unaware and I’ll give it a really curious example.
Mike Shinn: [00:11:54] Some years ago when I worked at the GSA we had these large Oracle servers these these giant Unisys servers. I don’t even know Unisys made servers. They made these big huge multi CPU multi RAM servers that Oracle ran on and they all happened to run Red Hat Linux. It just so happened that the systems also happened to run and came from the factory with this embedded Windows operating system that was basically the management layer for these devices. And it was a complete unknown to the organization there. Nobody knew that that was there. You know it’s not like somebody was keeping it a secret. It’s just the presumption was we have a server, it has Red Hat installed on it and it’s running Oracle therefore it’s a Red Hat server. And they didn’t learn that in fact it was more than that until somebody did a pretty thorough vulnerability test on. So in some cases organizations may not even know that they have vulnerable platforms in their organization and even if they feel that they’re reasonably knowledgeable about the stuff that’s in the organization.
Mike Shinn: [00:13:10] I mean how many people realize that their operating system is running on their printers. You know it probably don’t even think about it that way. It’s a printer. Why does it have an operating system. It’s got a web server on it.
Bret Kinsella: [00:13:21] Yeah let’s say you have more and more. That’s right. Well there’s functionality we expect in our printers today that we didn’t in the past. So Atomicorp has one of the more popular Linux OS versions and it’s popular because it has a hardened kernel. And at some point the company was notified that hey there’s a hardware flaw on certain chips. Your operating system might be able to protect against that flaw. So what did Atomicorp do? You know generally in order to work with the hardware manufacturers to fix this problem.
Mike Shinn: [00:13:58] Yes so. So we definitely fall into the category of of most paranoid when it comes to things down at the kernel level on operating systems. It’s something that we’re known for that we don’t consider the standard security measures that are in most operating systems kernels to be adequate. It really goes to the philosophy that we apply to cybersecurity which is that we need to be proactive about vulnerabilities and not reactive about them. So we had already been thinking about the class of attack that this really fell into many months in advance and one of the challenges that we have in cybersecurity is that you know we’re all beholden to what people ultimately believe that they need. So sometimes when you build a countermeasure for something that not everybody agrees is necessary. People don’t want to deploy it. And certainly at this level of engineering it’s challenging to say the least because it’s down in the weeds of minutia of memory management and other really esoteric aspects of how hardware and operating systems behave.
Mike Shinn: [00:15:15] So a Meltdown is one of these examples of how we still as an industry haven’t figured out how to do this very well. That isn’t to pick on any particular party in this equation. This is one of those challenging vulnerabilities that belies something that I talk about quite a bit that you know patching is undoing cybersecurity because we have become more than just dependent upon it. It’s almost a dogmatic belief that in patching is is an adequate solution when it’s not. So in this particular case you know we we learned about this vulnerability through what are sometimes referred to as responsible disclosure policies which basically means that certain trusted parties get to know about these particular vulnerabilities so that they can fix them secretly in the hopes that bad guys don’t find out about it. And somewhere along the way the details of this particular vulnerability started to get out to the media and the intent was for this vulnerability to be what’s called release from embargo or it’s not embargoed anymore. It’s not a secret. And we had everybody in the industry had to move up our plans for putting out a fix for this. The advantage that we had though is the solution that we used for Meltdown is very different from what others did. We have a technology in our kernel. This is very similar to what everybody else ended up adding into their kernels to try and deal with this. So it’s a more evolved an advanced version of what they ended up doing so we already had a lot of this technology already.
Mike Shinn: [00:17:03] You simply had to apply it to a greater degree than we always were. So we didn’t have to invent something. We were already there. We also didn’t have the growing pains that some vendors had where because they had radically changed the way that they were managing memory. They ended up breaking some vendor’s products and we already had accounted for those things in the way that we did it. So we have a… we’re dealing with these problems every day. This is one of our areas of specialties I guess I would say. And so this was not a surprise to us I guess is the right way to describe it. I mean we know these platforms are incredibly complex and you know looking at it we’re like “yeah that makes sense that that that particular combination of factors allows these systems to be exploited to expose information that they shouldn’t”. It was it was not a hard pill to swallow for us it was “Yeah. OK we see that”. So we were ahead of the game in that sense. But you know as an industry this is very challenging to try and keep these things secret and somehow along the way that information got out to the public sooner than it should have. And that’s unfortunate. All right.
Bret Kinsella: [00:18:27] Well Mike thank you very much for talking to us about Meltdown Spectre. And I presume then end users businesses that are concerned about this for Spectre you see to make sure that you have the most recent versions of the browser installed for whatever your browser provider is and for Meltdown you should be make to make sure for systems that have chips that are affected by this that you’ve loaded a newer version of the OS.
Mike Shinn: [00:18:56] Yes. And don’t assume that that’s the case right. Certainly you should ensure that for whatever versions of whatever it is that you’re using that the vendor has stated unequivocally that they have fixed these particular issues because there were many fixes that went out that didn’t quite do it or may… and in some cases some platforms had to block updates because the fixes from Meltdown were crashing the systems if other pieces of software on the system weren’t upgraded in advance. So just because the computer says “Yes you’re fully patched” may not actually be fully patched if the system has disabled those patches to prevent the system from crashing. So a little bit of diligence is worth it here especially since this vulnerability effectively encompasses nearly everything that we use.
Bret Kinsella: [00:19:52] Right. Well the good news is most of the media storm, firestorm has died down largely because we haven’t heard about a big attack that originated in this area that a lot of the work that had been done seems to have prevented it. I’m sure we will hear in the coming months or years about someone’s hack and it all went back to Meltdown. Someone else it’ll either be the truth or some will use it as an excuse. But at least today I think it is a go forward basis, everyone has a way to protect against this For the affected chips.
Mike Shinn: [00:20:24] There are definitely solutions out there that you can use. One last comment that I will have is that we probably don’t know that these attacks have occurred because they are not possible to detect a system that isn’t patched. So if someone’s being attacked via this it’s extremely unlikely that they would know it. And since these attacks involve theft of information it’s even less likely because there’s probably not going to be any overt manifestation of the attack occurring on the systems. So definitely make sure that that you’re up to date on your patches right.
Bret Kinsella: [00:21:05] And don’t expect an alert because you’re not going to see one. Just make sure you fix your system.
Mike Shinn: [00:21:10] I wouldn’t expect any alerts at all.
Bret Kinsella: [00:21:12] Thanks Mike.
Mike Shinn: [00:21:13] Thank you.
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.