Episode 019: Meltdown and Spectre Vulnerabilities

The computing world has been afflicted with the emergence of two nefarious vulnerabilities called Meltdown and Spectre. Thinking that you just might be invulnerable could prove to be very costly and a whopper of a pain in the butt. Please listen in as Ivan Stegic, TEN7's President and Founder, and Tess Flynn, Devops, discuss these two vulnerabilities and help you understand and cope with their impact.

Here's what we're discussing in this podcast:

  • The recent disclosure of the Meltdown and Spectre Vulnerabilities
  • What are the vulnerabilities
  • Who's affected
  • How they work
  • How long have we known
  • What can be done to protect yourself

TRANSCRIPT

IVAN STEGIC: Hey, everyone you're listening to the TEN7 audiocast where we get together every Fortnight to speak plainly about technology business and the humans in it.  I'm your host Ivan Stegic, and in this episode of the podcast... Meltdown and Spectre, the hardware vulnerabilities that seem to affect every computing device in existence, ever. To help me wade through the fear, uncertainty and doubt this has inevitably caused is TessFlynn, Devops engineer here at TEN7. Hey Tess.

TESS FLYNN: Hello.

IVAN: Are you scared?

TESS: I had a very long evening after that was disclosed, a very very very long evening.

IVAN: Yeah, the names just make it sound awful.

TESS: They're getting better at choosing the names at least.

IVAN: It's true. It's true. So two vulnerabilities were announced to ring in 2018 with a bang right. So let's start by talking about the names of each of them, and maybe who announced them.

TESS: So there are two vulnerabilities, but they both are very similar to each other. There's Meltdown and then there's Spectre. They were both discovered by Google Project Zero, and a number of other individuals as well working with Cyberus Technology, University of Pennsylvania and Maryland, Technical University of Graz and the University of Adelaide. You can find a complete list of everyone on meltdownattack.com

IVAN: So you mentioned they were announced by Google's Project Zero team, who is that? Who are they?

TESS: They're are a security research group inside of Google.

IVAN: So their basic mission is to find all the vulnerabilities, I would imagine. 

TESS: Because as Google is a very large cloud service provider, they are susceptible to unknown attacks and unknown vulnerabilities. So they research a lot of operating systems, a lot of hardware in order to find those vulnerabilities, and we're finding lots of them.

IVAN: Why do they do that?

TESS: Why does Google research this or why do we keep finding vulnerabilities?

IVAN: While I suppose we could answer both questions, but I mean I kind of have an idea why they do this for themselves, but it feels like there's a bigger service to humanity that they're performing.

TESS: That's kind of one of the things you have to have in credo if you're an InfoSec kind of person. If you find a vulnerability, it is your responsibility to disclose it. You should also disclose it in a very particular way so that the people who can find the ways to patch and fix the problems are informed first before the bad guys are.

IVAN: And so there's actually a fine line between finding the vulnerability and when you actually publish it online. I can't imagine that the large companies that effectively control our infrastructure didn't know about this vulnerability before it was announced to the public is that right?

TESS: That's correct. They actually discovered this vulnerability, Project Zero discovered this vulnerability as far back as July of last year. However. I did a little a little hackery research this morning, and I found evidence of a previous mailing list, which found the implication of this vulnerability 11 years ago, but they didn't quite understand the potential of it back then.

IVAN: Whoa! That's a long time ago.

TESS: Yeah, I found that out this morning.

IVAN: Wow. Well so you talked about Meltdown and Spectre. Shall we talk about what the actual vulnerability is because they're different, but similar you said maybe you could explain them in layman's terms. 

TESS: Yeah, there's a lot of different explanations on how this is. The Raspberry Pi Foundation did a very good explanation of this that's very technically adept. Several other more layman's descriptions of it that you can find online, and I'm not a CPU person so if I get this wrong, please don't like destroy your phone or your laptop in anger. One thing that modern processors do is they do something called speculative execution. So it's like you're walking down a road, you stop because there's a fork in the road. If you are a bit of code going through the CPU and your progress through the the road is the CPUs execution, which path you take depends on some condition. Let's say if it's Tuesday you go left. If it's Wednesday you go right, something like that. The CPU is going to look at what you did, what the preponderance of other variables are and then it's going to execute both paths for you before you ask it to execute one or the other. And the reason why it does this is because if you actually start executing one of those paths and it turns out to be the right one, you just saved several nanoseconds of time in execution. If on the other hand that right path is wrong you throw the rest of the work away, and you don't care because you executed the other path as well. Now that sounds great. This is a huge win for performance, and it was like that for twenty-plus years since the Pentium was announced.  So there's a problem. In a processor architecture that doesn't do speculative execution, the CPU will wait for you to say, "Execute this branch."  Now if in that branch you say, "I want to access the fancy super secret operating system memory that I most certainly should not access because I'm an application, the hardware is going to go "No!" and just slam you down with the ban hammer because you're not supposed to do that. And that's great, but in modern CPU architecture, which does do speculative execution, the CPU goes oh, I'm going to execute this branch speculatively because you didn't ask me to do it, and now I'm not going to check if you should be accessing that memory. And then the trick is what you can do is force the CPU to execute differently, then check the cached result of that execution, which contains the memory that you're not supposed to access.  This is why it's called a side-channel attack and it's kind of dangerous, because all modern CPU architectures do speculative execution. All of them, it doesn't matter if you're odd Intel it doesn't matter if you're at AMD, it doesn't matter if you're on ARM. I haven't checked the mainframe yet or the spark or the even Alpha guys, but you know I don't think we need to worry too much about them. This this kind of speculative execution attack is very very dangerous. Now, there are two vulnerabilities. One is called Meltdown which is much more closer to the way I described it. There's also Spectre, which is another way of executing the same kind of attack, but what it does it chains through another application to cause that application to execute in ways that it's not supposed to. And because the way that you can force this hardware behavior looks like perfectly normal code. No antivirus will catch it. It doesn't matter what operating system you're running on. If you're on Mac OS if you're on Windows, if you're on Linux, it doesn't matter... you are vulnerable. 

IVAN: Let me see if I understand this. The fundamental issue here is that the main processor of any computing device is trying to increase its performance by guessing, or by doing both processing branches of a question you might be asking it, and then when you actually decide which parameter you're providing to the processor it chooses one of them and discards the rest. You called that speculative processing, and there are two vulnerabilities one of them is called Meltdown and the other one is Spectre that somehow exploits the results of those multi-branch processing streams that get done.

TESS: That's correct. I did see some performance reviews of how quickly you could dump a system's memory using Meltdown, it was up to 500k a second, which was kind of terrifying. Spector was 53k a second, which is still pretty terrifying.

IVAN: What devices does this affect and what operating systems does it affect? You alluded to Windows, Mac OS and Linux, but are we talking about every single device, or is that just fear?

TESS: Spectre affects virtually every consumer-oriented device that's been manufactured in the last 20 years. Meltdown affects primarily any intel-based system that has been developed since the Pentium. So that's still a very long time and a lot of systems. And because this is built into the hardware, this isn't operating system vulnerability. this is part of the of the hardware itself, this vulnerability is irrespective of operating system.

IVAN: That's bad.

TESS: That's very bad. It's very very very bad. That's why I had a very long night the day that this was announced. Fun fact, they actually had to disclose early due to an information leak. They were going to announce it this week, not last. That's why some of the operating systems don't have patches yet. 

IVAN: Okay, so every device. Every mobile device every desktop device every server device. If you have a computing device that you use the internet you're likely affected, and that's that's as plain as as as from what I can tell. Now, let's talk about the fact that the vulnerability exists. But what could effectively happen if I am a user and I am on my desktop computer, or I am on my phone in a coffee shop somewhere or at home. What is an example of something that might happen to a user because of this vulnerability?    

TESS: So one proof-of-concept attack that I did actually see involved five lines of JavaScript that would exploit a Meltdown susceptible process or to dump all of its system memory. That would include any passwords, logins, Keys, anything.

IVAN: That's bad.

TESS: That's very very bad, and this was demonstrated with the slightly older version of Chrome. So this could actually affect a lot of people who don't have their systems up to date. 

IVAN: So from a user's perspective some lines of JavaScript could take advantage of this vulnerability, assuming that the systems aren't patched just yet. How about for a company that has a website and is running a website in the cloud maybe with a provider like Squarespace or has managed hosting, what about their risk?

TESS: So the problem is that both of these require you to execute some code on the server. With a provider like Squarespace, which you really don't have any kind of API that you can access. It's all through a GUI,  you're relatively safe there because their front door is already guarded with a huge massive portcullis. Whereas if you are running a web server on your own infrastructure or a cloud infrastructure that is still possible to be vulnerable especially if you allow your users to upload things. Especially if you allow them to upload anything that might be executable. And there's always the possibility of chaining vulnerabilities. Someone might take a compromised JPG to launch a buffer overflow which does an SQL injection that eventually uploads code, which runs the Spectre exploit.

IVAN: So what you're saying is, it's not just that you're vulnerable to Spectre and Meltdown, but these things these vulnerabilities could be used with others in tandem, one after the other. So it's it's a little more serious than than just the vulnerability itself, and they're being in the exploit.

TESS: Right, but you also have to remember one thing, that kind of chain attack is incredibly sophisticated and usually requires dedicated action by corporate or state actors in order to execute. It requires some human ingenuity. Most attacks today are drive-by attacks. These are done by massive botnets to see if they can find any kind of exploits use a regular pattern to extract whatever kind of wealth that they can get. And this is one thing I was wondering about earlier today was, okay so if someone does exploit this, what are they going to do, because even in software exploits there are trends, and we're actually starting to see the trend of using ransomware, the the act of force encrypting an entire system so that you have to pay them to unlock it. That's actually getting less popular now. It used to also be a we used to do a lot of personal information mining. That's not popular anymore either. The big popularity in exploiting computer security is in mining crypto currency. You can make money much more directly from that, and if you get arrested you're going to probably be able to plead to a lesser charge because you didn't actually compromise anybody's accounts. You just stole CPU time.

IVAN: And you also still have access to your wallet and your private keys so you're probably not going to lose that either. So besides security issues are there any other issues that have been caused as a result of these vulnerabilities?

TESS: Right now we don't know because they were just announced. My guess is that there will probably be some Meltdown attacks that are going to become in the wild pretty much, if not today very very soon. However most operating systems are getting patched as we speak. So the attack surface is decreasing quickly for that. We can patch for Meltdown so we can close that particular vulnerability. Spectre we can kind of patch for but, there's a big but there.

IVAN: So we don't know if there are any exploits in the wild just yet.

TESS: No not just yet not that I could see, but there's always the possibility that someone's going to do it. 

IVAN: Now what about performance? I read this weekend that some online services have seen an increase in the amount of CPU utilization that they've encountered that they've had on their services as a result of patches that they've applied.

TESS: Yeah in terms of one of the ways of this is getting patched is called the kernel page table isolation patch -- if I got that correct -- KPTI. That particular patch basically creates a virtual memory space that's accessible for each application to call particular operating system API's. Now before we didn't have any kind of barrier and that for most Linux's. Now that there is an additional layer that adds a number of CPU instruction cycles on top of each one of those calls. Most of those calls are going to be like two or three instructions, so there's a non-trivial but not catastrophic performance hit for most workloads. I've actually updated my own laptop to use the KTPI patch. I have not noticed any performance degradation. I'm using a regular desktop workflow. Someone I do follow on Twitter had their Mac OS system recently updated, and their CPU fan is running constantly now. They're not that's related to this patch, or it's an unrelated issue. We don't know. But more scientific analysis has shown that degradation of performance between one to three percent is fairly common, and the worst case is up to 30% performance degradation. 

IVAN: So that might be problematic in systems that are already running at Peak capacity, but might be okay, if those for those that are running below 50% for example.

TESS: Right. Modern data center techniques though usually stress allocating and provisioning out as much resources possible, because idle research resources waste money, so there's going to be there's going to be some additional charge and adding this particular security. Now the good news is that all of the major Cloud providers should be patched now. Google had already patched their Google Cloud environment before disclosure. Amazon was in the process of patching it when the vulnerability was disclosed Azure went down the next day probably because they didn't do so well deploying out for patch. But I believe they're back up now.

IVAN: That's good so. So let me ask you about let's assume that someone's written an exploit and has has been able to deploy the code somewhere that has affected a user. As a user, can I even tell if someone's used it against me?

TESS: Probably not.

IVAN: So there's no log. There's no trace. There's nothing that is a fingerprint that this leaves behind?

TESS: You might notice an increase of disk space or network use or CPU utilization, but the honest truth it's going to be very difficult to detect because it doesn't look like virus software. To any antivirus tracker out there, it's a few lines of very creatively constructed memory execution and then in terms of Meltdown. That's a lot harder to exploit right now there a lot of security researchers are saying that is very difficult to actively exploit. But human beings are rather creative individuals, so I'm going to hold my breath on that one.

IVAN: So just by the very definition that it happens very quickly in a CPU and in the memory that is associated with that CPU, there is a very very very tiny chance that there's going to be any log of those events anywhere. So what you're saying is there's a vulnerability. We don't know if there's been an exploit in the wild yet. We have a proof-of-concept that can exploit the vulnerability, and if someone has used it against me, I don't actually, like there's a very small chance that I would know that it's happened because they really it doesn't really leave a trace of any sort.

TESS: Correct.

IVAN: Okay.  What could I possibly be losing? What is leaking? What data is leaking? What it every sounds like it's the brain of everything so potentially anything?

TESS: in terms of Meltdown it is virtually the entire contents of your memory. No matter if it's in applications, or if it's in the operating system.

IVAN: So any keystroke I've made. Any password I've put in. Any wireless key. Any bank account details. Any illustrator.

TESS: A wonderful GIF that explains Meltdown that shows one application running a password entry field and the other one with a terminal application using the Meltdown exploit. You can see it in plain text every key stroke.

IVAN: That sounds that sounds awful.

TESS: It is awful.

IVAN: Okay. Now that we have sufficiently scared everyone, provided factual information and tried to explain this to our listeners, what do you think the best case scenario is for us moving forward?

TESS: When genetically engineered Apes takeover?  Okay, update update update update update update update update. I cannot say this enough. If there's an update for your operating system, for your browser, for your phone update now. Please drop everything now. Stop. Hit pause and update.

IVAN: Go and update your system.

TESS: This is a very very bad exploit, which is going to affect everything that connects to the internet and everything that has a CPU, and not only your phones, not only are laptops, not only your desktops, but any any game consoles Smart TVs anything with an internet connection. Your light bulbs might have this exploit in it.

IVAN: Your router.

TESS: Yes.

IVAN: So gaming consoles as well of course because they have CPUs. Anything that is a device of any sort, Ok, so the best case scenario you're describing is everybody updates with the latest operating system the latest browser latest patch, and we have a chance of reducing the attack surface. What's the worst case scenario?

TESS: A targeted attack on a specific individual would be virtually catastrophic. You would be able to extract the entire treasure trove of information on a person's system downloaded of off of a high-speed internet connection, use it to do all sorts of nefarious terrible things. So it's it's bad. It's very very bad.

IVAN: In that worst case scenario though, there is a human element to it as well though, isn't there. It's not like using a device on the internet, it can be exploited. In the description that you gave of five lines of JavaScript, I would still have to go to a website and a load a website that is a nefarious or that has been hacked to have that happen to me. Correct?

TESS: That is correct. So all of the same basic computer security and safety procedures still apply. Don't open attachments that you don't know. Don't go to websites that you don't trust. Please please try to go to only sites that use https and that are encrypted instead of ones that are open to everybody. These are very basic things, but they still will protect you a lot more than you think. Use password managers too.This is another one that doesn't get nearly enough drum beating in my opinion. But don't ever, ever use the same password for two different accounts. Never. And the reason why is because eventually one of those passwords will be compromised. We have seen that over the last year with multiple massive compromises of password databases. If you only have that one password for that one service the rest of your services are fine, and there's plenty of tools that you can use theirs LastPass, there's 1Password. There's open source ones like KeyPass or just the Unix pass command all of those are really excellent password managers that can take care of managing and generating those passwords for you.

IVAN: There's another open source one that I just discovered last month called BitWarden, and it is free to use and you can download it and install it yourself and host it yourself and use their cloud service, which I was delighted to see so I agree with that. Password management, and it's not just sufficient to have different passwords for different accounts.  But perhaps changing them every so often as well. I like to do that at the beginning of the year so My My January usually looks like changing all the major passwords is as much as I can.

TESS: The most secure password is the one you don't know, that you can't memorize, the four common words thing is bullshit.

IVAN:  That brings us to the end of this episode. Tess, thank you so much for sharing your insights with us today. It's been a pleasure to speak with you. Live long and prosper.

TESS: Peace and long life.

IVAN: You can find us online at TEN7.com/podcast. That's TEN7.com/podcast. This is Ivan Stegic. Thank you for listening.

Ivan Stegic

Founder and President
 
Image
Ivan Stegic

Ivan spends most of his time on strategy and championing our clients’ needs. He loves to figure things out, and relishes the chance to work with others to come up with sound technical solutions. He’s worked as a Physicist in R&D for large companies like Honeywell and Imation, but after starting TEN7, he hopes to continue working in small, closely knit teams that are able to have true impact with their work.

Tess Flynn

DevOps Engineer
 
Image
Tess Flynn

Tess is a recognized expert in the Drupal field with experience in Drupal 7 and 8 development. She has assisted in the creation of web platforms for Fortune 500 companies, and is the module maintainer for Flag 8.x, Examples, and Flag Friend. Tess is a world-class mentor and educator, having spoken at Drupalcon, BADCamp, and Midcamp.