Placeholder Image

Subtitles section Play video

  • So imagine if JavaScript could just read anything on your computer.

  • If some tab on your browser just had access to reading all your passwords or knowing what

  • your other programs are doing.

  • That would be pretty bad, wouldn't it?

  • By a computer I of course mean any kind of computing device, like your smartphone.

  • What would be particularly worrying is if this were to happen without exploiting any

  • software vulnerabilities or without fooling you to do so.

  • That's actually the state of affairs right now.

  • We are currently seeing a series of attacks called Spectre and Meltdown, in what I'm going

  • to call here the "Spectre Meltdown".

  • I'm want to explain the core of these vulnerabilities to a wider audience.

  • I'm going to skim a lot of the technical details.

  • So we're not going to go into some of the necessary technical details that make exploitation

  • possible.

  • But I just wanted to give you the idea of what these vulnerabilities are doing.

  • My name is Ymir Vigfusson and I'm Assistant Professor of Computer Science at Emory University.

  • Before we get started, I just wanted to give credit where credit is due.

  • These vulnerabilities were found by actually concurrently separate teams, who have done

  • fine work on writing up the details, and I encourage you to look at it.

  • So let me introduce the three ingredients that are we are going to need to understand

  • the attacks.

  • The first one is to understand how memory works.

  • At a high level.

  • The second one is to understand "speculative execution" in your CPU.

  • And the third one is something called "side-channel attacks".

  • Naturally, Spectre and Meltdown are at the convergence of these new kinds of attacks

  • that are becoming particularly worrying as, well as hardware errors that are also worrying.

  • So it's in the intersection of something that we need to be looking out for in the coming

  • future.

  • Let's get to it.

  • How does your computer work?

  • Well...

  • Let's take it at a really high level, simplified view of your computer.

  • A computer is really a bunch of different components that are strung together.

  • These components include things for input/output, like your monitor, and your keyboard, your

  • mouse.

  • And then there is a CPU in the middle that does all the processing.

  • And finally, there is memory, and I'm counting hard disks or SSDs as being part of your memory.

  • Really what happens when you are doing something on your computer is that you're going to load

  • a program from a disk, and it's going to be executed by the CPU.

  • Your CPU is going to do a bunch of computations, and those computations involve memory, so

  • it's going to go back and forth a bit.

  • And finally it may produce some output and that output may end up on your monitor, on

  • through the network.

  • That's basically what execution on a modern computer looks like.

  • So let's zoom in on the CPU and memory.

  • Inside your memory you actually have contents of all the different kinds of programs that

  • you're currently running.

  • This could be programs you're running; it could be data pertaining to the operating

  • system that you're running, like Linux, Windows or MacOS, and so forth.

  • And it's your user data.

  • Memory is an amalgam of all these different types of things that could be used, as well

  • as storing intermediate computations for the CPU.

  • Let's look at memory a little bit more in detail.

  • There is a lot to a memory hierarchy inside a computer.

  • If we think about memory, it's actually very helpful to just visualize it as a long sequence

  • of boxes that you can open.

  • Each box contains one bit, or one byte of information in our case.

  • There are actually several layers of memory.

  • What I've drawn here is something called DRAM, which is actually very big but veeery sloooow

  • for the CPU to retrieve.

  • If the CPU wants wants to retrieve some data from it, it has to wait for a while.

  • So what we have are actually several other layers called cache memory.

  • So let me draw cache memory here in front.

  • Suppose I wanted to open one of these boxes.

  • My request -- it's fast memory over here -- that this particular orange box over here be opened.

  • Well... it's going to taaake a whiiile.

  • Whereas if I try to open up a different box, if I open up this one, I can actually first

  • ask the really fast cache memory.

  • And that has an exact copy of what I need.

  • Now, the way cache memory is maintained is that when you retrieve something, you often

  • take a copy and put it into the cache memory so that the next time you might need it, you have

  • it laying around really quickly.

  • But cache memory is small, and tends to be pretty expensive.

  • So you have to kick something else out.

  • This is actually the subject of much of my research.

  • So!

  • This is how caches work.

  • Let's move on to the next ingredient.

  • What are side-channel attacks?

  • Now.. let me illustrate it with an example.

  • Suppose that you are asking a computer to authenticate, and there is a particular password

  • that the computer knows is there.

  • This has actually happened on several routers.

  • This is something known as a "timing attack".

  • This is a kind of a side-channel attack, but I think it illustrates the point.

  • Suppose the password is, randomly, "hunter2".

  • Now, what you might do is to start guessing.

  • You say, like, "Well, is the password 'a' ?"

  • And the computer has to run around and check if it matches.

  • It looks at the first character 'a'.

  • Looks at the first character of the password, and sees that it's 'h'.

  • It doesn't match and so it returns.

  • Now you might guess: "b?"

  • You do the same thing.

  • Of course, there are exponentially many possibilities here, and you'd be out of luck.

  • That's why passwords are often good.

  • But in this particular case, as you keep guessing.

  • You guess 'g?', same thing happens.

  • If you guess 'h?'

  • now, what you'll notice is that it takes a little bit longer for the computer to respond

  • to you.

  • And if that happens, that's because the computer had to look at the letter 'h', saw that it

  • matched, and then had to look at the subsequent letter to see if there was a match there.

  • There was no match, because you guessed a one letter password, and the password is actually

  • longer.

  • So now you might actually be pretty confident, just by looking at the timing information,

  • that the first character is 'h".

  • So you move on to 'ha?' and you see it takes just a long as what you guessed initially.

  • And then you would try 'hb?' and so on and so forth.

  • This actually makes password guessing linear in the length of the password, rather than

  • exponential, which is terrible.

  • The side-channel here is the timing information.

  • It's something about the physical implementation of this algorithms, this password-checking

  • algorithm, that you are exploiting.

  • In this case, the timing difference.

  • So, let's keep that also as an ingredient.

  • The third thing I wanted to tell you about is called "speculative execution".

  • This might be -- might look something like this from Rick and Morty.

  • When your CPU is trying to execute a bunch of instructions what it will run into is the

  • fact that memory is slooow, like we talked about.

  • So, you have your really fast CPU, it has a lot of gigahertz.

  • It's running around, it's executing stuff.

  • And what it runs into is that, ultimately, your program is going to need some data from

  • memory.

  • So it talks to memory, and then you're just waiting for the response.

  • And the response takes a whiiile.

  • So you're spending a lot of your time just waaaiting for meeemory.

  • That's an absurd way of having a CPU go about its business.

  • So, 20 years ago, what people came up was: "well, what if we just make our CPUs do speculative

  • execution?"

  • What I mean by that is that, suppose your program looks something like this.

  • There is a branch -- there is an IF sentence that depends on memory in some way.

  • There's really only two options.

  • Either, what you're going to get from memory is going to be 0 in this case, or it is not.

  • So what if you just guess?

  • You think that maybe the most likely thing to happen in this case is that you're going

  • to get a zero from memory.

  • Now, you are waiting here for memory and you decide to just sprint ahead.

  • You come here, and you just execute the instructions that are coming, even before you get your

  • response from memory.

  • Huh... interesting.

  • So if memory is 0, you're actually ahead of curve: you know what's going to happen.

  • You can resume from instructionD onwards.

  • It's very convenient.

  • Now, if that didn't happen -- if it so happens that the response from memory wasn't zero,

  • then you actually have to roll back all the changes that you made.

  • So have to be very cognizant of not changing the state of the program, registers externally,

  • so that you can actually go back to the other branch of that IF sentence.

  • This is very interesting.

  • Now, the flaw that Spectre and Meltdown are exploiting is the fact that actually when

  • you're doing speculative execution, the state of the CPU actually looks a little bit different

  • because of cache when it has to abort a branch.

  • Now we actually have all the ingredient needed to explain Spectre and Meltdown at a very

  • high level.

  • Suppose we have our memory here.

  • This is our slow memory.

  • And, as we talked about before, what your operating system kernel is doing is that it

  • allocated this memory to different applications, or possibly different virtual machines if

  • you're living in the cloud.

  • That means that there could be adjacent parts of memory allocated to different victims.

  • I'm pretty much describe Spectre right now, but the same concepts apply to Meltdown.

  • So there is part of memory here, what we call victim memory, that we want to enumerate.

  • We want to know what it says.

  • It could contain a password that we're after.

  • Normally, what an operating system tries to do is to make sure that your program, including

  • your JavaScript in your browser, cannot access somebody else's memory.