It’s not just nasty names…
TL;DR:
- Yes, it is really bad
- Patch as soon as you can
- Reboot when your cloud provider tells you
- Practice safe online practices
- Don’t panic.
Introduction
For the past few days there has been a lot of speculation on why certain Linux kernel patches were rushed through.
Somewhere last night, researchers from various origins lifted the shroud and released the so called ‘Meltdown’ and ‘Spectre’ attacks via https://meltdownattack.com.
In this blog post I will try to give you my take on these two attacks and what they mean to defenders and users of CPUs (yes, that’s you).
What are these attacks?
Meltdown and Spectre are two attacks that abuse performance optimisation features of CPUs to gain access to memory that should have been off limit.
While we like to think of computer programs as sequences of statements that get executed sequentially, this is not actually true in modern operating systems. For performance reasons CPUs sometimes execute commands ‘out of order’. This happens e.g. when a CPU has issued a statement that will take a while to complete, in stead of idly waiting for this command to finish the CPU will already execute the next few instructions that wil likely occur so it can ‘work a little ahead’.
The meltdown paper, uses this example:
If we imagine that the raise_exception() call will take a while to actually raise the exception, the CPU will execute the commands on line 3 ahead of time. Once the exception occurs and the CPU ‘realises’ that the code should not have executed it will disregard the results of that statement and thus not affect the normal execution of the program.
The researchers have found out that this mechanism can be abused to gain access to data one should normally not have access to and that this data can then be stored in a so called ‘side channel’ which can then be accessed with another piece of code.
Meltdown specific
The Meltdown attack uses out of order execution to gain access that is normally security stored in ‘kernel memory space’. Normal processes don’t have access to this memory space unless a special bit is set on the processor to allow access to this memory space. When this bit is set, the processor is in ‘system’ mode, if it is unset, the processor is in ‘user’ mode.
Meltdown exploits a race condition that exists when statements are executed out of order. While statement 1 has started but not yet finished, the CPU is in system mode. Statement 3, which is executed out of order before statement 1 finishes is able to fetch data from kernel memory space, because the CPU is still in system mode. Another bit of code is then actually able to read this information from the cache side channel in a clever way.
For performance reasons the kernel memory space also contain a map to (almost) all of the physical memory on the machine. This did not use to be a problem, because user processes could not set the CPU in system mode and could thus not access the data at these addresses, but Meltdown has melted this security boundry.
This is especially worrying in situations where the OS kernel is shared between user. This is for example the case with (docker) containers and in para-virtualised cloud environments like Amazon AWS and Microsoft Azure. In the case of containers, one container can read the memory of all containers on the same server. In case of cloud, one customer can ready the memory of all VMs on the same hypervisor, including those of other customers.
Spectre specific
While Spectre shares certain mechanisms and characteristics with Meltdown, it also differs.
Spectre attacks a different scenario in which code is executed in Out of Order, the so called ‘Speculative Execution’. They give the following example:
This code is exploitable to read outside the bounds of array1. In order to do this the attacker has to:
- Call this bit of code a number of times with a valid value for x to ‘train’ the CPU into speculating that, while it waits for the computation of the length of array1 line 2 is the next statement that needs to be executed.
- Then call the same code again with a value of x that forces y to become a value read outside the bounds of array1
- Read the value of y from the cache side channel
There are various situations where this type of code can be found to occur naturally in the code of a program, but in cases where you can execute code within a program you could even write this code yourself. These cases are a lot more frequent than we think. Examples are programs that support macros, systems that support third party plugins and of-course browsers that execute JavaScript.
In fact the researchers have even provided a JavaScript sniplet that, when executed with the right parameters in Chrome, can read all memory assigned to Chrome, basically breaking JavaScript memory isolation and the Same Origin Policy.
Mitigation
While CPUs have mechanisms on board to erase the artefacts (results) of instructions that execute while they shouldn’t have, the results of these executions can still be obtained via the cache side channel. Eradicating this bug, would e.g. require modification of the mechanism that ‘cleans up’ after wrongfully executed instructions.
Out of order execution is built into the hardware, along with the ‘cleanup’ mechanism. It cannot be patched via the CPU firmware. So swapping CPUs is the only real way of eradicating the vulnerability.
The operating patches that are now being prepared by Microsoft, Apple and Linux do not actually ‘fix’ the bugs in the CPU either. They modify the OS kernel in such a way that the Kernel Memory Space does not provide access to the physical memory anymore, this avoids that these bugs can be exploited to gain access to the physical memory.
Because only Meltdown uses Kernel Memory Space, these patches only work against Meltdown, but not against Spectre.
Which is worse?
This is a hard question to answer.
Meltdown is easier to exploit than Spectre and gives access to all the physical memory of your server or your hypervisor. But, it’s consequences can be addressed with patches.
Spectre is harder to exploit, and only give access to the memory of the process it is exploited in. However there is no generic patch against the consequences of Spectre and it is going to be nearly impossible to patch against it in environments that run user supplied code inside their own processes (e.g. web browsers running JavaScript).
The immediate danger from Meltdown is without a doubt higher than that of Spectre, especially for (customers of) cloud providers. However, once patches to mitigate Meltdown are installed, Spectre is a much more persistent problem that is going to make the internet a much less safe place.
What should I do?
Against Meltdown
If you are running an operating system, patch it as soon as possible. Meltdown breaks a fundamental security mechanism of your OS and you should do whatever it takes to restore it.
Be aware that some anti-virus software isn’t compatible with some of Microsoft changes.
If you have VMs or Containers in Cloud, you provider will need to patch for you. Follow the instructions of your provider. If they say you can reboot your machine to get the patch, do it a.s.a.p.
Against Spectre
There is not much you can do. It cannot be patched and replacing your CPU with one that isn’t vulnerable is not a viable plan of action.
The internet just got quite a bit less safe. But you can do some things:
Consider to use different browsers for different tasks. One for banking and other critical task and one for recreational use.
Enable two factor authentication wherever possible. With 2FA some part of how you authenticate is not stored in memory.
Consider a script blocker like NoScript or uMatrix (1|2).
Be careful when you install browser plugins. They are third party code running in your browsers and if they use the Spectre attack they can read everything that goes through your browser.
Don’t panic
The world isn’t ending yet, we can mitigate Meltdown and Spectre like attacks are complex. Obviously browser vendors are looking at mitigating measures for this type of attack.
Bron: Blog Schuberg Philis
