Why Spectre and Meltdown vulnerabilities are not phantom menaces?

The disclosure of the Spectre and Meltdown[1] vulnerabilities are of one those examples showing that cyber threats can impact us all, anywhere, anytime. Having turned a low-level hardware feature into a massively scalable software attack, the recent Spectre and Meltdown issues illustrate the necessity to assess security at each step of the design process with state-of-the-art tools and a strong cyber security expertise.

Trusted Labs has developed for several years a strong expertise in micro-architectural attacks and countermeasures.  Jean-Henri Granarolo, Trusted Labs ITSEF Technical Manager gives us detailed explanations on what the Spectre and Meltdown vulnerabilities are and what can be done to prevent them.

spectremeltdown

What are Spectre and Meltdown and what are the impacts?

Spectre and Meltdown are two similar security vulnerabilities which were designed and have been proven to impact processors from companies such as Intel, AMD, ARM and possibly others. These security vulnerabilities allow a bypass of existing software isolation mechanisms (such as kernel/user memory isolation or sandboxing solutions). This means that the vulnerabilites make it possible for any user of a Central Processing Unit (CPU) to access memory areas supposed to be restricted to admins or other users, for instance to steal secret passwords or keys. They can potentially be applied on standard PCs, smartphones, IoT devices, cloud servers…  In the case of the Meltdown attack, memory extraction could be performed remotely and at a rate of up to 503 KB/s!

Talk nerdy … how does it work?

Out  of order execution and kernel memory

Let’s get more into the details. On some CPU’s such as most modern Intel processors (even back to the Pentium Pro from 1995), the execution of instructions is actually not linear, but parallelized and not necessarily in the expected order – this is called “out-of-order execution”. This optimization allows the processor to use all of its execution units in the most time-efficient way, without impacting the behavior of the programs.

In the most popular operating systems (Linux, Windows and Mac OS), the virtual memory layout of processes also contains the mapping to the kernel memory, to speed up context switches between user and kernel.

Normally the user cannot access kernel memory because isolation mechanisms require the CPU to be in privileged mode for the access to be authorized, but aggressive out-of-order execution can in some cases perform the access before the security check itself. The result of this invalid access is never visible to the user because it is only stored in temporary registers; however it can lead to micro-architectural modifications visible through side channel attacks*.

This technique, named “Meltdown” by its authors and registered under CVE-2017-5754, can for example be leveraged to disclose kernel memory from a user process.

Speculative Execution

Another optimization mechanism is called the Speculative Execution. For example, when the CPU encounters an “if statement” with 2 branches, it can decide to execute the most probable branch verifying the outcome of the “if” condition. This is the case in particular when the “if” condition execution requires an access from the main memory, in order to prevent the CPU from wasting precious cycles.

Even if a program follows secure coding practices, such as bounds checking before performing an array access, the processor can be tricked by an attacker into speculatively executing an out-of-bounds access. Indeed, after executing the legitimate branch a given number of times, the processor prediction unit will predict this branch as the most probable and it will be speculatively executed. As with the out-of-order execution, the results of the out-of-bounds access will never be visible from the user; only side-effects such as the cache state modification will be visible.

Two different vulnerabilities exploiting these mechanisms were reported as Spectre and registered under CVE-2017-5753 and CVE-2017-5715. They can be leveraged to trick another process, such as a virtual machine for example, into disclosing its memory to the attacker.

Side-channel attacks

A side-channel attack is an attack method which deduces secret data from a side-effect of an operation manipulating the secret data (the “side-channel”). For instance, a possible side-channel is the amount of electrical power consumed to load data into a register. The side-channel used in the original exploitation of Spectre and Meltdown is the access time to memory in the CPU cache. The feasibility of cache timing exploitation is a crucial criterion to determine the level of risk regarding Spectre and Meltdown. In the worst case, this can be done remotely, by executing a small software in a non-privileged process.  Since the emergence of micro-architectural attacks a few years ago, Trusted Labs has designed its own tools to evaluate the resistance of any processor.

How do I protect my activities from these vulnerabilities?

First, let’s point out that software patches for Spectre and Meltdown exist and can be applied. Still, the released patches do not cover all the possible cases. Earlier in this article, we explained that Spectre and Meltdown are based on side channel attacks, in particular cache attacks. Thus, it is important to perform an evaluation of your component’s resistance to those attacks.This is an important lesson to draw. Side channel attacks have been known for more than 20 years  Side channel attacks for many years were perceived as non-scalable or non-remote. Meltdown and Spectre are examples that show that this is no longer true: Some side channel attacks can be performed remotely and are scalable. Today side channel attacks MUST be taken into account when designing and evaluating your product. It is not a nice-to-have, but a must, vital to business continuity and to the overall brand image of your service or product.

The other take-away message is the importance of isolation. These attacks demonstrate that any hole in the process isolation mechanism can result in a full memory disclosure. Therefore, expert advice is  vital when choosing and deploying an isolation solution.

Once your product and design have been analyzed by Trusted Labs, we will be in a good position to identify with your engineers the best methods to protect your business and customers: from immediate software patch to stronger design improvements.

For more explanation, please contact us.

[1] https://meltdownattack.com/

Jean-Henri Granarolo, ITSEF Technical Manager

Jean-Henri started in Trusted Labs in 2011 as a Security Consultant.
He has worked in various fields related to embedded security, from smart cards to Digital Rights Management and Trusted Execution Environments. He has been working on internal tools used during security evaluations, including side-channel attack tools since 2015.