Plundering of crypto keys from ultrasecure SGX sends Intel scrambling again

For the past two years, modern CPUs—particularly those made by Intel—have been under siege by an unending series of attacks that make it possible for highly skilled attackers to pluck passwords, encryption keys, and other secrets out of silicon-resident memory. On Tuesday, two separate academic teams disclosed two new and distinctive exploits that pierce Intel’s Software Guard eXtension, by far the most sensitive region of the company’s processors.

Abbreviated as SGX, the protection is designed to provide a Fort Knox of sorts for the safekeeping of encryption keys and other sensitive data even when the operating system or a virtual machine running on top is badly and maliciously compromised. SGX works by creating trusted execution environments that protect sensitive code and the data it works with from monitoring or tampering by anything else on the system.

Key to the security and authenticity assurances of SGX is its creation of what are called enclaves, or blocks of secure memory. Enclave contents are encrypted before they leave the processor and are written in RAM. They are decrypted only after they return. The job of SGX is to safeguard the enclave memory and block access to its contents by anything other than the trusted part of the CPU.

Raiding Fort Knox

Tuesday’s attacks aren’t the first to defeat SGX. In 2018, a different team of researchers broke into the fortified Intel region after building on an attack known as Meltdown, which, along with a similar attack known as Spectre, ushered in the flurry of processor exploits. A different team of researchers broke SGX earlier this year.

Intel mitigated the earlier SGX vulnerability by introducing microcode updates. However, these mitigations did not last, as two new attacks have sent Intel scrambling anew to devise new defenses. Intel released the new updates on Tuesday and expects them to be available to end users in the coming weeks. Depending on the computer, the fix will either be installed automatically or will require manual intervention. Users, particularly those who rely on the SGX, should check with the manufacturer of their machine and ensure that the update is installed as soon as practical.

The new SGX attacks are known as SGAxe and CrossTalk. Both break into the fortified CPU region using separate side-channel attacks, a class of hack that infers sensitive data by measuring timing differences, power consumption, electromagnetic radiation, sound, or other information from the systems that store it. The assumptions for both attacks are roughly the same. An attacker has already broken the security of the target machine through a software exploit or a malicious virtual machine that compromises the integrity of the system. While that’s a tall bar, it’s precisely the scenario that SGX is supposed to defend against.

Stealing attacker-chosen secrets

SGAxe is able to steal large chunks of SGX-protected data of an attacker’s choice. One class of sensitive data is that belonging to the target user—for instance, wallet addresses or other secrets used in financial transactions involving blockchains. The picture on the left immediately below this paragraph shows an image file that was stored in a secure enclave. The one on the right shows the same image after it was extracted using SGAxe.

Credit: van Schaik et al.

The attack can just as easily steal cryptographic keys that SGX uses for “attestation,” or the process of proving to a remote server that the hardware is a genuine Intel processor and not a malicious simulation of one. A remote server can require connecting devices to provide these attestation keys before it will carry out financial transactions, play protected videos, or perform other restricted functions. In a paper titled SGAxe: How SGX Fails in Practice, researchers from the University of Michigan and the University of Adelaide in Australia wrote:

With the machine’s production attestation keys compromised, any secrets provided by [the] server are immediately readable by the client’s untrusted host application while all outputs allegedly produced by enclaves running on the client cannot be trusted for correctness. This effectively renders SGX-based DRM applications useless, as any provisioned secret can be trivially recovered. Finally, our ability to fully pass remote attestation also precludes the ability to trust any SGX-based secure remote computation protocols.

Unfixed for five months

SGAxe has its genesis in an earlier attack, called CacheOut, that the same research team (with one additional participant) revealed in January. CacheOut, in turn, is a variation of an attack, disclosed in May 2019, variously known as RIDL, Fallout, ZombieLoad, and Microarchitectural Data Sampling, with each moniker coming from a separate research team that independently discovered underlying flaws. Both CacheOut and SGAxe exploit CVE-2020-0549, a vulnerability that the researchers behind the RIDL attack disclosed as an addendum on January 27, the same date the CacheOut paper was published.

RIDL and the other related exploits generally allowed an attacker to read data packets processed by a CPU that they shared with a target. In essence, RIDL is analogous to a glass placed on a wall that allows one apartment dweller to hear what was happening in an adjacent unit. The apartment in this metaphor would be the Intel CPU, while the wall would be the line fill buffer, or a region on the silicon that stores recently accessed data. Just as the wall leaks sound, the buffer leaks timing data that allows attackers to infer the data it contains.

Intel never fixed the underlying vulnerability in the silicon. Instead, company engineers issued a microcode update that caused CPUs to overwrite buffer contents with garbage every time the processor began a new security-sensitive operation. CacheOut figured out a way to bypass this mitigation.

More potent

Besides bypassing the mitigation Intel put in place in 2018, CacheOut introduced a way to make exploits more potent. A limitation of the original RIDL attack is that it allowed attackers to monitor only conversations actively taking place in the adjacent apartment, i.e., access to only the data that was being processed in the hyperthread. There was nothing an attacker could do to access data if it wasn’t being processed in the hyperthread shared by the same CPU core. Using CacheOut, however, an attacker can overcome this constraint. More specifically, in CacheOut the attacker first evicts data of her choice from the cache, a process that on Intel machines sends the data to the line fill buffer, where it can be extracted using RIDL. If RIDL was like using a glass on the wall to listen to a conversation in an adjacent unit, CacheOut was the way the attacker could force the participants to discuss any topic the attacker wanted.

SGAxe, in turn, describes a new, more potent use for CacheOut. It uses a memory management scheme known as paging to move enclave data into the L1 cache, where the contents are decrypted. From there, CacheOut moves the data into the buffer, where it’s extracted using the RIDL technique.

The Intel spokeswoman said that, once the microcode fix is installed on end-user machines, it will reassign the attestation security keys to account for the possibility of the old ones having leaked. The spokeswoman also said that the severity of any attestation-key exposure can be mitigated when attestation services use the Intel-recommended linkable signature mode to detect fraudulent use of platform keys. She also said that SGAxe and CacheOut have “little to no impact in virtual environments that have applied” a mitigation released in 2018 to protect a different speculative execution flaw known as L1 Terminal Fault.

Daniel Genkin, a University of Michigan researcher and one of the co-authors of the SGAxe and CacheOut papers, said linkable signature mode isn’t always practical to use and doesn’t mitigate the threat of leaked attestation keys in all instances. He also disagreed that the L1 Terminal Fault mitigation prevents CacheOut and SGAxe attacks, although he said it made the attacks harder.

But wait... there’s also CrossTalk

The second SGX attack is notable because it’s based on a previously unknown side channel created by an undocumented buffer that all Intel CPU cores use. This “staging buffer,” as researchers from Vrije University in Amsterdam and ETH Zurich call it, retains the results of previously executed offcore instructions across all CPU cores. Here’s a diagram of how this intercore buffer works:

Credit: Ragab et al.

The discovery is highly significant for a couple of reasons. First, the staging buffer retains output from RDRAND and RDSEED, which are among the most sensitive instructions an Intel CPU can carry out because they provide the random numbers needed when generating crypto keys. The diagram below shows how the leak works:

Credit: Ragab et al.

Attackers who obtain the random numbers can use them to deduce the key. That finding allowed the researchers to devise a speculative execution attack that extracts a key based on the ECDSA cryptography algorithm as it is generated in an SGX enclave.

The first cross-core attack

Equally important, the side channel provided by this newly discovered staging buffer allowed the attackers to create the world’s first-known speculative execution attack that works across CPU cores. All previous attacks have worked only when an attacker and a target used the same core. Many defenders took that to mean that allocating trusted and untrusted code to different cores provided meaningful protection against speculative execution attacks, which are also known as transient execution attacks. CrossTalk, as the new exploit has been named, will force researchers and engineers to revisit that assumption.

“As an example,” researchers wrote in an email, “many believed disabling Intel SMT (hyperthreading) was sufficient to stop the majority of known/future attacks. Moreover, all attacks so far could be mitigated by simply running mutually non-trusting code on separate cores. We show that the problem goes even deeper and core-based isolation may not be sufficient."

In a research paper, the researchers summarized their findings this way:

The cryptographically-secure RDRAND and RDSEED instructions turn out to leak their output to attackers via this buffer on many Intel CPUs, and we have demonstrated that this is a realistic attack. We have also seen that, yet again, it is almost trivial to apply these attacks to break code running in Intel’s secure SGX enclaves.

Worse, mitigations against existing transient execution attacks are largely ineffective. The majority of current mitigations rely on spatial isolation on boundaries which are no longer applicable due to the cross-core nature of these attacks. New microcode updates which lock the entire memory bus for these instructions can mitigate these attacks—but only if there are no similar problems which have yet to be found.

The researchers tested Intel CPUs released from 2015 to 2019 and found evidence that the majority of regular client CPUs, including Xeon E3 series processors, are vulnerable to CrossTalk. Intel said that the server-microarchitecture in the Xeon E5/E7 aren’t vulnerable. The researchers haven’t tested any 10th-generation Core CPUs released this year, but based on information they received from Intel, they believe that some are.