Meltdown & Spectre and what it means for Intel SGX

We are occasionally asked about the implications of the recently disclosed Meltdown and Spectre CPU vulnerabilities on the security of Intel® SGX and secure enclaves. This post answers the questions we encounter and addresses the concerns regarding application security in light of these vulnerabilities.

Meltdown & Spectre 101

What Meltdown and Spectre have in common is that both techniques exploit speculative execution. Speculative execution is intended to speed-up programs by performing multiple instructions in parallel, often before the program can know for sure that the instruction is indeed needed, or valid in the current execution context (to be precise, Meltdown exploits out-of-order execution, but we consider it speculative since in that context the instruction is actually invalid). The objective of both attack techniques is to infer the content at a physical memory location that should not be accessible to the attacker. For instance, the attacker could try to have a peek into the memory space of the operating-system's kernel, or into the memory of another process.

MELTDOWN

Meltdown exploits the fact that the CPU executes instructions in the pipeline out of order, including potentially prefetching a memory address that should not be accessible in the attacker's execution context. When it gets to the stage of committing the result it would actually check whether the memory access was legal and discard the instruction in case it wasn't. However, at this point, it is too late, since certain subtle information, such as the time it took to access the memory is already available to the attacker. The Meltdown paper [Lipp et al.] illustrates it with the following toy-example:

raise_exception();
access(probe_array[data * 4096]);

The result of the memory-read in the second line is not supposed to be committed since an exception is raised right before that. However, due to out-of-order execution, the memory address is nevertheless accessed. It has the side-effect that the content is read into the cache, which is observable by an attacker using a cache side-channel.

SPECTRE

Spectre exploits conditional branch prediction to execute instructions that would not be executed normally, and pull otherwise inaccessible memory content into the cache. The CPU is "trained" to expect a certain sequence of instructions to happen. For instance, in the following example, as long as the if condition is fulfilled, the assignment to y is executed.

if (x < array1_size) {
   y = array2[array1[x] * 256];
}

By executing the block multiple times, the attacker could train the branch-predictor to assume that the line would be executed (regardless of the value of x). The attacker then triggers the execution of this block in the context of the victim process, or the kernel, with values of x larger than array1_size, in order to access memory addresses that are outside the bounds of array2. Combining it with a cache side-channel, the attacker is able to infer the content seen by victim process.

An important observation, made by the researchers who disclosed Spectre,  is that speculative execution was only observed when the destination address was accessible by the victim thread. It implies that, unlike in Meltdown, exploitable code has to actually be present in the executable memory of the victim. That makes it non-trivial for attackers to execute a Spectre attack, since they first need to identify vulnerable gadgets within the target.

So what does it mean for secure enclaves?

While leveraging similar techniques, and having the common theme of virtual memory protection  bypass, Meltdown and Spectre are, in fact, somewhat different. Spectre exploits vulnerable code (gadgets) in another process, or in the kernel. Meltdown, on the other hand, attempts to access normally inaccessible virtual addresses within the attacker's process itself, i.e. within the same "execution context". Thus, Meltdown and Spectre have different implications for enclaves.

ANJUNA'S SECURE-RUNTIME CAN PROTECT CRITICAL APPLICATIONS AGAINST THE MELTDOWN ATTACK USING ENCLAVES

An enclave has a different execution context in the sense that it gets access to decrypted content within the Enclave Page Cache (EPC), whereas any other execution context only gets to see the content in its encrypted form. An attacker that attempts to read from an inaccessible memory location using Meltdown, will be redirected to an abort page, which has no value. In this Git repository, we provide sample code that demonstrates how SGX protects against Meltdown.
Eventually, Intel is likely to address Meltdown with a micro-architectural solution, but until that happens the recommendation is to deploy OS-level protections such as KAISER. In zero-trust environments, one cannot count on OS-level protection to protect against the Meltdown exploit, since we need to take into account powerful attackers who might disable KAISER and KASLR, and enable mapping of kernel pages into the attacker's process memory.

Spectre is currently outside the threat model of Intel® SGX. However, Spectre can be mitigated by making sure that the code running inside the enclave does not provide easily exploitable gadgets, and applies protective measures on the application level. Intel has recently released guidelines that can help harden code running within enclaves against Spectre. In addition, it is important to monitor public announcements that point to potentially exploitable gadgets within known applications, in as much as we, security practitioners, are used to monitor CVEs that disclose traditional vulnerabilities. Working closely with our customers, we carefully inspect the applications that we help secure, to make sure they are hardened against side-channel attacks.