Meltdown and Spectre security flaws

Experts are still debating how to fix the latest Meltdown and Spectre flaws: http://money.cnn.com/2018/01/03/technology/computer-chip-flaw-security/index.html

It’s all good,
We can all attend the up coming class tomorrow.

1 Like

The short-term solution to Meltdown is done, and is in the process of being packaged and shipped. All major OS/hypervisor vendors have a kernel-level fix that solve the immediate issue, so now it’s just a matter of getting the patches out and installed everywhere. There are a LOT of IT folks working over the weekend this weekend, and over many weekends to come.

Spectre, on the other hand… that one’s nasty to fix. It’s much harder to exploit than Meltdown, and requires way more access to the system you wish to exploit, and actually making sense of the data that leaks out is a huge challenge. And the exploit is based around core functionality of all processors.

I work for a major cloud/infrastructure as a service provider. We’re patching all of our cloud hosts this weekend for Meltdown. Thousands and thousands of them, with their many thousands of upset customers demanding we defer for their individual scheduling needs.

Xenpocalypse is upon us.

1 Like

https://boingboing.net/2018/01/05/damp-squids.html

So what’s the performance impact, if any, for any given os/cpu??

People have been speculating that it’s between 5 and 30% to fix.

OUCH!
Any breakdown on os vrs cpu, etc.
Thinking older systems will take bigger hit.
Just sucks…

It’s not really an OS/CPU question, it’s a program/application question.

The more syscalls you have, the bigger the performance hit. DB servers will see a big hit, on the order of 30%+ depending on OS/CPU, whereas app servers that don’t do a lot of writing to and from the kernel will see almost no hit.

OK. Sounds like desktops/laptops running sftwr like cad/cam and simulations won’t take that big of regardless of os/cpu.

Both of these flaws center on “speculative execution.”

What is that, you may ask?

In the early days, given some code like this:

if A:
	do This
else:
	do That

the CPU first determines the value of A, then does either This or That.

Then the chip makers hit hard physical limits on how fast the chips can run. But they were not limited on the size they can make a chip. So instead of each generation of processor being several times faster than the one before, designers began adding more transistors to enable processors to be more efficient. Pipelining, barrel shifters, wider word sizes and parallel arithmetic units can only go so far.

They were eventually able to put multiple processors onto a chip. Since software had to be specially written to take advantage of parallel processing, the designers looked for ways to execute a single thread of program instructions quicker.

So while part of the chip is busy figuring out the value of A, other parts of the chip are starting to do This and That. Once A has been determined, the results of doing either This or That are kept and the other is discarded. In a nutshell, this is what is known as speculative execution. Both potential paths are executed and the correct one is kept.

The flaw is that the two speculative execution paths are not subject to the same security restrictions as regular code. The problem comes when either This or That attempts to compromise system integrity. The result of that path may be eventually discarded, but the fact that part of the chip executed faulty code can be used to access sensitive memory contents.

Part of the fix is to rearrange sensitive system memory so the the speculatively executed fragments cannot access memory they do not own. Part of it is reduce the amount of speculative execution which can be done. The current patches do some of these. The quoted performance losses are the cost of giving back some of the gains from speculative execution.

And part of it is to tighten access by speculatively executed code fragments - this can only be done by replacing the processor.

Some more interesting reading material:

https://seekingalpha.com/article/4135651-intel-meltdown-spectre-vulnerabilities-explained

https://www.extremetech.com/computing/261439-spectre-meltdown-new-critical-security-flaws-explored-explained

3 Likes

I don’t think the researchers have released full proof of concept code for Meltdown yet, but some working code has already been posted on github by an apparently unrelated party. Contrary to what we’re hearing from media channels, these are not difficult vulnerabilities to understand or exploit.

Spectre in particular seems like it should have been obvious enough to anyone with strong knowledge about modern pipelining architecture and an interest in security. And even if you weren’t privy to the specific egregious shortcut that Intel has taken which makes Meltdown possible, all you’d have to do is be curious enough to write some test code to find out, like this guy did last summer:

https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

It seems absurd to me to think that this class of vulnerabilities was only just noticed by someone last year. It’s much more likely I think that at least one naughty agency with good intel on Intel is quite unhappy that one of their favorite undetectable exploits for the past 20 years just went public.

1 Like

Heads up - Google Chrome is apparently not yet patched against Spectre and won’t be until later this month, but in 10 seconds you can change one setting and that will work around the problem and keep you safe.

Enabling chrome://flags/#enable-site-per-process * is the recommended workaround according to Google, and should prevent malicious web pages from stealing information out of other tabs or banking logins out of your saved passwords for instance.

It’s not unreasonable to imagine that there could already be dozens of malicious web pages looking to profit from stolen saved passwords or bitcoin private keys or whatever else is sitting in your Chrome memory space. If I had any sensitive passwords saved in Chrome, I’d be changing them right now after enabling the setting mentioned above.

*ok this link isn’t clickable because reasons, so just copy and paste it into chrome

Here’s an expansion on @Bill’s post to explain the exploit in more detail than any source I’ve found other than the two research papers which I’ll link at the bottom.

I’ll describe Meltdown but Spectre is nearly identical. The difference is that where Meltdown bypasses a security check made within Intel processors giving it access to all system memory, Spectre bypasses a check in the OS or a program to get access to all memory within the process it runs in. Both exploits take advantage of speculative execution to leave behind a modification in unprotected data to the L1 cache which is dependent on the value of protected data, and then later determine what modification was made to the cache by timing reads of unprotected data to see which data was cached during the nefarious speculative execution and therefore learn what the protected data was.

I’ll pick it up at the part where we know that we can make the processor execute some code speculatively but we know also that the effects of such code will be discarded or rolled back. Code which is executed speculatively is not permitted to do things like write to RAM or print to the monitor until after the processor determines that it was ok to be executing the code in the first place. So we need to design some kind of code that we can have the processor execute speculatively which will somehow leave behind information that survives the discarding of results when the processor realizes that this code shouldn’t be executed and rolls it back.

Consider the following pseudocode in which protected_data represents some data that our code is not permitted to read. The first line of code will generate an error and abort the rest of the program, but (on an Intel processor) this check is made concurrently while the remaining lines of code continue to execute speculatively. Eventually the processor will complete the check and roll back the effects of the last 4 lines before those effects propagate to the rest of the computer, which is why we can’t simply print the data out straight away.

x  = read(protected_data)
if x == 1:
    read(unprotected_data_1)
else if x == 0:
    read(unprotected_data_0)

So at first it seems like there should be no way for us to do anything to retrieve protected_data because the effects of whatever code we write after reading it are rolled back before we could do anything to retreive data out of the processor. However the problem is that there is one effect which is not rolled back at all, and that is any change made to the L1 cache inside the processor. Again, this does not at first seem helpful, since the restrictions against reading protected data still apply regardless of whether we’re reading out of the L1 cache or RAM. Whatever we’re going to do the L1 cache during our speculative execution, it will have to be something that we’re permitted to read later on so that we can actually get the results out of the processor.

Looking again at the last 4 lines of code, it isn’t immediately obvious that we’re doing anything helpful. Even if this code weren’t going to get rolled back, what good could reading unprotected data do? Why aren’t we trying to write x to somewhere or print it out? Well it’s all about the operation of the L1 cache, the fact that changes to it won’t get rolled back, and the fact that we’re perfectly allowed to access unprotected_data.

Consider now the pseudocode below. We want to run this code after running the code above. This time however we aren’t doing anything disallowed and no speculative execution is involved. We’re simply going to run some code and it’s going to tell us whether the bit of protected_data from above was a 1 or a 0.

timer1.start()
read(unprotected_data_1)
timer1.stop()

timer0.start()
read(unprotected_data_0)
timer0.stop()

if timer1 < timer0:
    print "protected_data was 1"
else:
    print "protected_data was 0"

The key here is that it will take a different amount of time (2 orders of magnitude longer) to read data that is stored in RAM than it would take to read the same data if it had already been read and copied into the L1 cache previously. By comparing the time it takes to read our two unprotected_datas, we can determine which unprotected_data had been read and copied into the cache earlier during our speculative execution, and since which one we read earlier was dependent on the value of protected_data, we have just learned the value of protected_data.

3 Likes