George Wainblat

George Wainblat

George Wainblat joined Unbound in June 2017 as Director of Product Management. George brings a wealth of experience in leading multi-disciplinary product, engineering and business units at global hi-tech companies as well as startups.

Foreshadow: When To Not Rely on Hardware

Since the publication of the Spectre and Meltdown attacks in January this year, security researchers have been taking a close look at speculative execution and it’s security implications.

Recently, research independently conducted by two groups of researchers (a first team from KU Leuven in Belgium, and a second team from the University of Michigan, University of Adelaide, and Technion) lead to the discovery of the Foreshadow vulnerability.

Foreshadow is a speculative execution attack on Intel processors which allows an attacker to steal sensitive information stored inside personal computers or third party clouds. Foreshadow has two versions, the original attack designed to extract data from SGX enclaves and a Next-Generation version which affects virtual machines, hypervisors, operating system kernel memory, and System Management Mode memory.

The Foreshadow vulnerability was made public on August 14, 2018, after the research groups privately notified Intel as a part of responsible disclosure in January 2018.

Before understanding Foreshadow implications, we need to first look at the goals of Trusted Execution Environments and their ecosystem.

Trusted Execution Environments

TEEs are secure environments where both the code and the data are protected to ensure their confidentiality (nothing else on the system can see their contents, even code with root access) and integrity (any tampering of the code or data can be detected).

Several large vendors utilize TEE architectures in their hardware design:

  • AMD – Platform Security Processor (PSP): This TEE subsystem is responsible for creating, monitoring and maintaining the security environment and its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any suspicious activity or events and implementing an appropriate response.
  • ARM – TrustZone: This embedded security technology starts at the hardware level by creating two environments that can run simultaneously on a single core: a secure world and a not-as-secure world. As such, developers need to secure systems from the lowest levels, at the physical layer, which includes the boot up process.
  • Intel – Software Guard eXtensions (SGX): SGX is a set of central processing unit (CPU) instruction codes from Intel that allows user-level code to allocate private regions of memory, called enclaves, that are protected from processes running at higher privilege levels. Intel designed SGX to be useful for implementing secure remote computation, secure web browsing, and digital rights management (DRM).

Meltdown and Spectre showed that speculative execution has severe security implications. Meltdown (on most Intel and some ARM processors) allows user applications to read the contents of kernel memory. Spectre (on most Intel, AMD, and ARM chips) can be used to attack software sandboxes used for JavaScript in browsers and, under the right conditions, can allow kernel memory or hypervisor memory to be read. In the months since they were first publicized, we’ve seen new variants: speculative store bypass, speculative buffer overflows, and even a remotely exploitable version of Spectre.

Foreshadow Implications

For Foreshadow, the data of interest is the encrypted data in the enclave. The overall pattern is the same as with Meltdown – attempt to read enclave memory from outside the enclave, allow speculative execution to modify the cache based on that data that was read, and then have the processor abort the speculation when it realizes that it’s protected-enclave memory and that reading isn’t allowed. The attack depends on the fact that only data in main memory is encrypted: once it’s inside the processor in a cache, it’s decrypted. Specifically, if the data is in level 1 cache, the speculative execution can use it before the processor determines that it’s not allowed to.

Foreshadow demonstrates how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine’s private attestation key. Making things worse, due to SGX’s privacy features, an attestation report cannot be linked to the identity of its signer. Thus, it only takes a single compromised SGX machine to erode trust in the entire SGX ecosystem.

While investigating the vulnerability that causes Foreshadow, which Intel refers to as “L1 Terminal Fault”, Intel identified two related attacks, which are named Foreshadow-NG. These attacks can potentially be used to read any information residing in the L1 cache, including information belonging to the System Management Mode (SMM), the Operating System’s Kernel, or Hypervisor. Perhaps most devastating, Foreshadow-NG might also be used to read information stored in other virtual machines running on the same third-party cloud, presenting a risk to cloud infrastructure. Finally, in some cases, Foreshadow-NG might bypass previous mitigations against speculative execution attacks, including countermeasures to Meltdown and Spectre.

A Pattern is Emerging

Foreshadow is the last, but as it seems definitely not the least, in a long line of attacks, caused due to imperfect implementations in silicon. Foreshadow is the last link on a respectable chain of vulnerabilities turned into exploits, like Spectre and Meltdown beforehand. These attacks did not begin with Spectre and Meltdown, though they had an important role in awakening the general public and security experts alike, to the dangers lurking in the deep layers of hardware. Software side channel attacks such as page-based side channels and cache-based side channels as well as energy management attacks go a long way back to 1996. Speculative execution is just the latest branch of this somber tree.

It is most unfortunate to see a great company like Intel be the latest victim of the ‘root of trust’ vulnerabilities that occur in hardware, along with the extreme pain of recovering from such flaws.

Recovery from Hardware Design Flaw

In a paraphrase to Mark Twain’s famous wording on statistics, there are bad cases, there are terrible cases, and there are catastrophic cases when recovering from hardware design flaws:

  • In the bad cases, a software patch which remediates the underlying flaw is possible and can be distributed quickly and universally – but this always involves some compromise of either the functionality or the performance of the hardware.
  • In the terrible cases, a firmware patch to the hardware is required, that might take some time to receive due to the differences of roles between the chip vendors and solution providers.
  • In the catastrophic cases, no patch is possible, and you just have to throw out the existing hardware and start over with a new one, bearing the accompanied outage and unexpected expenses.

It almost doesn’t matter what the exact details are of a particular incident, like the one we are experiencing now with Foreshadow, or how transparent and effective the vendor’s response is.  This is because in any of these cases, you end up with a very expensive – and often a very protracted recovery process.  And in most of the cases you also end up with a system which has to operate indefinitely in a degraded mode (lacking speculative execution bear s performance penalty of up to 40%) after the recovery is complete.

Summary

Relying on hardware for critical trust-root components always puts you at risk of falling into the “recovery from hardware design flaw” antipattern for a system you can’t afford to leave vulnerable for any significant period of time. The conservative (and safe) approach would thus be not to rely on hardware for critical security properties of root-of-trust components.

As a result, it is prudent to switch from the reliance on hardware as the exclusive root of trust, to a reliance on software solutions that provide mathematically proven guarantees of security, along with the capability of quickly and easily patching any discovered flaw. One primary example is secure multi-party computation (MPC), which due to recent breakthroughs in computer science research, is now a viable and appealing alternative to hardware solutions.

Subscribe to BLOG

shares