CS356: Meltdown & SpectreOr... The Dangers of Caches and Speculation

Marco Paolieri (paolieri@usc.edu)Illustrations from meltdownattack.com

Virtual memory isolates processes, right?

Programs are not permitted to read data from other programs… and yet:

● Meltdown allows a program to access the memory (and secrets) of other programs and the operating system. It works in the cloud too!

● Spectre allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. Safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre. Harder to exploit but also harder to mitigate.

Wait, but:● Am I affected by the vulnerability? Most certainly, yes.● Where’s the problem? Out-of-order execution (Intel since 1995, some ARM)● Can I detect if someone has exploited them against me? Probably not.● Can my antivirus detect attackers? Unlikely until a binary becomes known.● What can be leaked? Anything in your RAM.● Is there a fix? OS patches against Meltdown, compiler patches for Spectre.

In practice: reading other programs’ memory

Meltdown: Melts HW Security Boundaries

Isolation between kernel and user processes● Supervisor bit in the CPU is set when entering kernel code.● Kernel memory pages can be read only then the supervisor bit is set.● No change of memory mapping between kernel mode and user mode.

● Meltdown uses side-channel information leaked by out-of-order execution to read kernel virtual memory.

● In the kernel virtual memory, there is a region that gives access to all of the physical RAM.

● It’s not a bug of the OS, but a problem of modern CPUs. All operating systems are affected.

So, what’s the problem with out-of-order?

Out-of-Order and Speculative Execution

Out of Order. While the execution unit (ALU, LD, ST) of the current instruction is busy, other instructions can run ahead if resources and data are available.

Speculative Execution. Let the CPU process instructions even when it’s not certain that they will be needed. If they are not needed, just undo their effects (rollback); otherwise commit.● Example: instructions after a branch

How? Tomasulo’s algorithm (1967)● Queue instructions in scheduler● Connect all units with CDB● Run them when data is available● Rollback if order was wrong

Cache Side-Channel Attacks: Flush+Reload

Flush+Reload1. Attacker frequently flushes the shared last-level cache (clflush)2. Checking the time to read from an address, the attacker determines

whether data within the same line was read by the user.

Variant: Evict+Reload. Instead of clflush, force eviction through many reads.

Covert ChannelThe attacker flushes the last-level cache and tries to access an address. Why?To let some information leak from one security domain to another.

An example: guessing the value of data

● After the exception, the flow continues in the kernel.● The exception handler terminates the program.● But due to out-of-order execution, the array access is performed…

… and rolled back later when the exception happens.But the effects on the cache are still present… a cache line was read.

Guessing values of kernel data

Transient InstructionsCompleted but not committed(they introduce a side channel)

● Accessing kernel data from user-space causes an exception.

● If we have instructions that use that data, they will certainly be rolled back.

● Can we leave a trace of the data in the state of the microarchitecture? Like, in the cache?

Avoiding the exceptionThe exception will terminate your attack program. Solutions:● Do the illegal access from a child process, recover secret data from parent● Trick the branch predictor into thinking that the illegal code should run, when

it won’t: this schedules your code, without an exception.

Sending data through the covert channel

Very simple!

● Fix a monitored memory address x● The transient instruction reads kernel data and transmits it 1 bit at a time

○ Flush the cache; if the bit is 1, read from x● The recovery code (in user space) reads from x

○ If the read is fast, the value was 1

Using many addresses in different cache lines, we can transmit multiple bits at a time.

Meltdown can transmit data at 500 kB/s. Not bad!

KASLR

Kernel Address Space Layout RandomizationSame as ASLR, but instead of randomizing the stack position, randomize the position of the kernel virtual memory.

Enabled by default in Linux 4.12

The location of the physical memoryrange is also randomized… ● but only by 40 bits● it takes 128 tests to cover 8 GB

So, it can be circumvented.

Linux KAISER Patch

Stronger isolation between userspace and kernel spaceDon’t map kernel data in user-space virtual memory(except for a few things like interrupt handlers)

Now KASLR is usefulThere is little kernel dataIt’s hard to guess where it is

Meltdown doesn’t work on AMDProbably because access bits are checked in the page table before LD/ST

Out of Order Execution + Side Channels

4-Step Recipe for a Meltdown

1. Vulnerable out-of-order CPU allows an unprivileged process to load data from a privileged address (kernel and all physical RAM) into a register.

2. The CPU performs computations based on the value of this register (e.g., use the register as array index).

3. If it turns out that we didn’t have the right to read the data, the results of these operations are thrown away.

4. Seems safe but… out-of-order memory lookups influence cache hit/miss: from this side channel, we can find out what the value was in the register.

Read the original paper!https://arxiv.org/abs/1801.01207

Spectre: The Risks of Speculative Execution

1. Locate or introduce a sequence of instructions within the process address space which, when executed, act as a covert channel transmitter leaking the victim’s memory or register contents.

2. Trick the CPU into speculatively and erroneously executing the instructions3. Retrieve information from covert channel.

How to trick the CPU into wrong speculations?

● Mistrain the conditional branch predictor.For example: if there’s an if guard, invoke it many times with valid data.Then pass invalid data… the branch predictor will take the “is valid” branch

● Mistrain the indirect branch predictor.For example: the attacker jumps many times to the virtual address of a gadget in the attacked program. The attacked program will jump too...

Spectre with branch misprediction

Idea● First use many valid x values● Then, pick x out of bounds to read

secret data of attacked program● array1_size, array2 not cached:

predictor has to guess wrong● Speculative execution causes a read

on page number equal to secret● We can scan all the pages and check

what the secret was from access times

It works in the browser too!

● Cannot use clflush for Flush+Reload, must use Evict+Reload● The clflush avoids optimizations, |0 triggers optimizations● The secret n will be used to access probeTable[n*4096]● Timing errors are possible due to other processes, but error rate is 0.005%

Processors at risk

Most● Intel

○ Ivy Bridge○ Haswell○ Broadwell○ Skylake○ Kaby Lake

● AMD Ryzen● ARM-based Samsung and Qualcomm processors

(And it works with native code or even sandboxed Javascript.)

Difference with respect to Meltdown● Meltdown does not mistrain branch prediction● Meltdown bypasses memory protection between userspace and kernel● Spectre does not: it just makes the CPU jump to the wrong place and run

instructions there to leak information. Cannot be fixed with KAISER.

Countermeasures

Preventing speculative executionVery expensive!

Preventing access to secret data● Run websites in separate processes● Replace array bounds checking with indexed masking to ensure locality● Pointer poisoning: (pointer XOR secret)

Only with secret you can recover/follow the pointer, and branch predictions use different statistics.

Prevent data to be leaked through cachesNot possible with current processors

Read the original paper!https://arxiv.org/abs/1801.01203