Another month, another way to smash Intel's SGX security. Let's take a closer look at these latest holes...

Analysis Intel's Software Guard Extensions, known as SGX among friends, consist of a set of instructions for running a secure enclave inside an encrypted memory partition using certain Intel microprocessors.

This so-called Trusted Execution Environment is intended to offer more security than is otherwise available to applications running on less fortified hardware. Nothing should be able to peer into or meddle with these enclaves, not even rogue system administrators nor malware. Sadly for Intel and those who depend on its technology, security researchers keep finding flaws in SGX.

On Tuesday, two separate sets of boffins published papers describing SGX vulnerabilities, but they're not really quite as bad as is claimed.

First, there's CrossTalk, which describes a novel transient execution attack – in which speculative CPU operations are spied upon to obtain sensitive data – that works across CPU cores.

In a paper [PDF] titled "CrossTalk: Speculative Data Leaks Across Cores Are Real," Hany Ragab, Alyssa Milburn, Herbert Bos, and Cristiano Giuffrida from Vrije Universiteit in the Netherlands and Kaveh Razavi from ETH Zurich explain that various Intel CPUs may conduct read operations using a staging buffer shared by the chip's cores.

"The contents of this buffer are visible to any core on the system that can execute these instructions—including non-privileged userspace applications within a virtual machine," the paper explains.

"The security implications of this behavior are serious, as it allows attackers to mount transient execution attacks across CPU cores, which implies that mitigations separating security domains at the granularity of cores are insufficient."

Using this finding, they devised a cross-core attack that leaks random numbers generated by the RDRAND and RDSEED instructions. Employed against SGX enclaves, the attack can compromise the randomness of cryptographic operations, an issue of concern particularly to cloud service providers that rely on SGX to secure their resources.

Intel refers to this as Special Register Buffer Data Sampling, which is similar to Microarchitectural Data Sampling, utilized in previously disclosed attacks like RIDL, ZombieLoad and Fallout.

The chip biz considers CrossTalk only a medium severity flaw because the ability to infer random numbers is only sometimes a security issue, depending on how those numbers are employed. If a number is used for a persistent key, then it's a problem; but it's used for a transient check of a session's state, then it's not of much value.

These Intel CPUs were tested by the researchers and found to be vulnerable to cross-core attacks:

• Intel Core i7-0850H (Coffee Lake) 2019
• Intel Core i7-8665U (Whiskey Lake) 2019
• Intel Xeon E-2288G (Coffee Lake) 2019
• Intel Core i9-9900K (Coffee Lake R) 2018
• Intel Core i7-7700K (Kaby Lake) 2017
• Intel Xeon E3-1220V6 (Kaby Lake) 2017
• Intel Core i7-6700K (Skylake) 2015
• Intel Core i7-5775C (Broadwell) 2015
• Intel Xeon E3-1240V5 (Skylake) 2015

For these systems, Intel has released a microcode update. Unfortunately, the update comes with a significant performance hit for two specific instructions because it locks the memory bus.

The two affected operations, RDRAND and RDSEED, require 16 micro-operations pre-patch and about 7,565 micro-operations post-patch, extra work that translates into an op-specific performance hit of about 97 per cent.

The impact on overall system performance depends on how often those operations are used. There's another issue too: Those operations, slowed down, become a source of potential denial-of-service attacks.

Intel Xeon Scalable, Intel Atom processors, and Intel 10th Gen Core processors (Comet Lake and Ice Lake), at least, are not affected. Below is a video demonstrating the exploitation of CrossTalk to leak an SGX key across a system's CPU cores in a second.

Youtube Video

Then, there's SGAxe, an elaboration on the previously disclosed CacheOut attack described by Stephan van Schaik, Marina Minkin, Andrew Kwong, Daniel Genkin (University of Michigan, US), and Yuval Yarom (University of Adelaide, Australia) in January.

CacheOut in turn followed from a set of previous attacks called RIDL, Fallout, and ZombieLoad that grabbed sensitive information as it moved through microarchitectural buffers. It also owes a debt to Foreshadow, which pioneered the use of the L1 data cache to extract SGX keys.

Intel refers to CacheOut as Microarchitectural Data Sampling (MDS) and previously issued a microcode countermeasure designed to overwrite targeted buffers with dummy data.

CacheOut, its details now more fully disclosed [PDF], demonstrated that Intel's countermeasures were insufficient. Instead of grabbing sensitive data like an encryption key from line fill buffers, it obtained data from the CPU's L1 data cache.

SGAxe, described in a paper by van Schaik, Kwong, Genkin, and Yarom, doesn't bring much new to the table. It's a transient execution attack utilizing CacheOut to obtain SGX attestation keys from a fully patched Intel machine. With this key, the attacker can sign attestation quotes that Intel's attestation servers take as genuine, thereby undermining SGX's reason for being.

"In this work we show that the security of the SGX ecosystem completely collapses, even in the presence of all currently published countermeasures," the boffins explained.

Their paper stated that CacheOut works even when the SGX enclave is idle, which means the attack bypasses software-based side-channel defenses like constant-time coding and mitigations that depend on enclave code.

Yet the paper neglects to mention that CacheOut mostly assumes Intel's Hyper-Threading is enabled, despite the consensus that emerged last year to avoid Hyper-Threading in security-conscious environments.

"Hyper-threading makes this attack significantly easier, but for CPUs like the Intel Core i9-9900K (stepping 13) and the Intel Core i7-8665U to pass Intel SGX remote attestation, it is not required that hyper-threading has to be turned off," explained van Schaik, one of the paper's co-authors, via Twitter.

Intel's microcode update mitigates the issue, which shouldn't be an issue for virtual environments that have already applied L1 Terminal Fault mitigations, developed in response to Foreshadow. ®