Spectre haunts Intel's SGX defense: CPU flaws can be exploited to snoop on enclaves
And no, you're not supposed to be able to do that
The Spectre design flaws in modern CPUs can be exploited to punch holes through the walls of Intel's SGX secure environments, researchers claim.
SGX – short for Software Guard eXtensions – is a mechanism that normal applications can use to ring-fence sections of memory that not even the operating system nor a hypervisor can access, let alone other programs.
These areas are called enclaves, and are typically used to run things like anti-piracy code without anyone spying on the decryption keys, or to run sensitive computational code on an untrusted remote machine. Attestation is used to ensure software on one box is talking to code running unaltered in an enclave on another box.
The speculative execution flaws revealed in January, however, jeopardize SGX's security boundaries, as demonstrated in the video below. As is to be expected, exploiting the chip-level vulnerabilities requires local access: a miscreant must be able to log in, or malware must be running in order to leverage the design blunder to attack an SGX enclave.
The researchers – professors Yinqian Zhang, Zhiqiang Lin, and Ten Lai, plus students Guoxing Chen, Sanchuan Chen, and Yuan Xiao – hail from Ohio State University in the USA. They've dubbed their enclave-sniffing technique SgxPectre, and noted on GitHub: “Similar to their non-SGX counterparts, SgxPectre attacks exploit the race condition between the injected, speculatively executed memory references and the latency of the branch resolution.”
In a formal paper, placed online this week, the team explained how a malicious program can influence a CPU core's branch predictor so that, when the processor is executing SGX enclave code, the contents of the secure environment's private memory and CPU registers can be observed via slight changes to the state of the cache.
Enclave code built using the Intel SGX SDK, Rust-SGX, Graphene-SGX, or similar runtime libraries, are vulnerable, we're told. These development kits include code patterns that can be exploited via SgxPectre to work out what lies within an enclave's secret memory.
The steps the researchers took to snoop on forbidden SGX data were as follows:
- Poison the branch target buffer to inject target addresses.
- Prepare the CPU so it's more likely to speculatively execute the secret-leaking instructions in the enclave code's SDK.
- Run the enclave code.
- Examine the monitoring array using a “flush-reload” cache side-channel attack to drip-feed out the contents of the enclave.
There is a fix: Intel's microcode update that introduced indirect branch restricted speculation (IBRS), which flushes the branch prediction history at the enclave boundary.
However, an evil sysadmin at, for example, a cloud provider could revert the patch, and “there is no means for the enclave code to reliably detect if IBRS is enabled.” This means enclave code running on a remote cloud machine can be snooped on by BOFHs, when the whole point of SGX is to securely run code on a faraway box.
The other microcode mitigations, Single Thread Indirect Branch Predictors (STIBP), and Indirect Branch Predictor Barrier (IBPB), have the same problem, that they mitigate speculative execution, but the enclave can't detect whether or not they're present. Thus, these defenses can be removed from a remote machine, defeating the purpose of the technology.
The Reptoline software-only mitigations don't protect SGX against SgxPectre, the researchers said. Intel is aware of their work, we're told
