Foreshadow

Security researchers from KU Leuven, Technion, University of Michigan and University of Adelaide, have recently published their findings on an attack called Foreshadow, that compromises the security of Intel SGX enclaves. Once again, speculative execution was exploited in a manner similar to the Meltdown attack.
In our previous post, we explained how Intel Software Guard Extensions (SGX) protect against a Meltdown attack attempted from the untrusted part of a process hosting an enclave. However, the Foreshadow team showed how one can use a Meltdown-like technique to read the victim enclave's memory, conditioned on sensitive data already being in the cache. The official disclosure of the vulnerabilities, named L1 Terminal Faultby Intel, took place on August 14th, 2018, and they were filed as CVE-2018-3615, CVE-2018-3646 and CVE-2018-3647.

In this post, we explain the implications of the attack, its mitigations via microcode updates, and how Anjuna helps ensure that a backend application is running on an updated hardware secured against this attack.

The Foreshadow attack on Intel SGX

SGX enables the creation of "secure enclaves", that enable an application to protect its sensitive data even from the kernel or a user with root access to the machine, effectively limiting the attack surface to the secure enclave interfaces, rather than everything else on the host.
The Foreshadow attack, discovered by Van Bulck et al. [2], leverages speculative execution and a cache-timing side-channel to extract information from enclaves.

MITIGATIONS

Intel mitigates this attack by flushing the L1 cache upon enclave exit events, which invalidates the requirement that Foreshadow relies on, that secrets should be present in the L1 cache in order for the attacker to be able to circumvent abort-page dynamics.
This update to the behavior of enclaves has caused a recent increment in the Security Version Number. In addition, to prevent attestation forgery, the old EPID group was invalidated and is no longer authorized by the Intel Attestation Service (IAS).
Intel released a security advisory for the issue, which it calls L1 Terminal Fault.

In order to make sure previously stored data will not be accessible (by reverting a microcode update), we recommend re-sealing and re-signing the data with new keys that can only be accessed by an up-to-date enclave with microcode updates deployed.

IMPLICATIONS FOR ATTESTATION

Attestation is a cornerstone capability of TEEs (Trusted Execution Environments), which enables a server application to provide a cryptographic proof to a client communicating with it, that it indeed runs inside a secure enclave, and assures that it is safe to send over sensitive data to it, or trust that its outputs are authentic. There are multiple ways to perform attestation, but all of them must rely on secure primitives to achieve their guarantees.
The most practical implication of Foreshadow is on the EPID-based Remote Attestation of enclaves. EPID attestation is based on a group signature scheme that enables to sign an enclave report, attesting to the initial state of the enclave, and cryptographically proving to a remote verifier that the report was generated by an authentic SGX enclave. The signing is performed using a key that is embedded in the processor and can only be accessed by the Quoting Enclave (QE). The extraction of this key enables an attacker to forge an attestation for any enclave identity. 

Anjuna does not use EPID-based attestation when anonymous attestation is not required, and unlinkability is not needed. Instead, we use standard PKI for most of our customer's scenarios. It is therefore sufficient to regenerate certificates and provision the enclaves with the corresponding private keys. The increment in the CPU Security Version Number (CPUSVN) guarantees that those new private keys are inaccessible to platforms where the security updates were not deployed. As such, the attestation mechanism is a perfect way to ensure that client applications are communicating with backend instances on properly patched servers.

BENEFITS OF SGX IN LIGHT OF FORESHADOW

Somewhat counterintuitively, we believe that some of the implications of Foreshadow actually strengthen the case for Intel SGX, and specifically for hardware-based remote attestation. As mentioned in the original Foreshadow paper [2], and in Foreshadow-NG by Weisse et al. [3],  the L1 Terminal Fault has implications reaching far beyond enclaves, to inter-VM scenarios, hypervisor memory inspection, separate processes running on the same physical core with hyper-threading, etc.
While the mitigations provided by Intel address the issues, users must ensure that the updates were actually deployed on the infrastructure they are running on. In this sense, Intel SGX can be extremely helpful in providing a signed report that notifies a remote client whether updates have been deployed, and which security features are activated on the host (for instance, whether HyperThreading has been turned off or not). Similarly to previous microarchitectural attacks like Spectre, Foreshadow actually strengthens the need for such attestation, even for scenarios where the operating system is trusted.

Architecture and Microarchitecture

We can reason about what goes on in a processor on various levels. One of them is the architectural level, that defines the semantics of executing programs, and the other is the micro-architectural level, which is how these semantics are actually implemented underneath.
On the architectural level, things have been pretty solid - the semantics of Intel Software Guard Extensions were formally verified by Subramanyan et al. [1]. However, on the micro-architectural level things have been discovered to be a bit shakier during the past year and a half. After several years during which cache-timing side-channel attacks were studied and perfected by researchers from academia and industry, the big blow came with the discovery of the Meltdown and Spectre attacks, concurrently and independently by Jahn Horn from Google's Project Zero, and by Paul Kocher (co-founder of Cryptography Research) and other researchers from academia and industry.
These attacks have shown that the assumptions about memory isolation between either different protection rings, or between different processes, are violated by micro-architectural side-channels that leak information across the architectural boundaries. For instance, Meltdown uses the fact that kernel memory is accessed speculatively from an unprivileged protection ring, leaving measurable effects in the processor's cache that leak content that should only be accessible to the privileged protection ring.

A silver lining in this story is the decoupling between the architecture and the microarchitecture. The Foreshadow paper explicitly states:

““We want to emphasize that Foreshadow exploits a microarchitectural implementation bug, and does not in any way undermine the architectural design of Intel SGX and TEEs in general. We strongly believe that the non-hierarchical protection model supported by these architectures is still as valuable as it was before.”

— Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution

Dealing with the complexity of Intel SGX

Anjuna helps its users to handle the complexities of SGX, and provides the tools that enable to take the necessary steps to restore security and privacy following such vulnerabilities, by migrating data to new enclave versions, and making sure new attestation keys are re-provisioned.

We are excited to see that the brightest minds in the security field from academia are researching Intel's SGX technology, over time helping make it one of the most secure solutions for application security and privacy.

REFERENCES

1. Subramanyan, Pramod, et al. "A formal foundation for secure remote execution of enclaves." Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2017.

2. Bulck, J. Van, Minkin, M., Weisse, O., Genkin, D., Kasikci, B., Piessens, F., Silberstein, M., Wenisch, T., Yarom Y., Strackx, R. (2018). Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. In 27th USENIX Security Symposium (USENIX Security 18).

3. Weisse, O., Bulck, J. Van, Minkin, M., Genkin, D., Kasikci, B., Piessens, F., Silberstein, M., Wenisch, T., Yarom Y., Strackx, R.(2018). Foreshadow-NG : Breaking the Virtual Memory Abstraction with Transient Out-of-Order Execution. Technical Report.

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 el.] 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.