Breaking

Saturday, March 3, 2018

New Spectre attack variant can pry secrets from Intel's SGX protected enclaves



A new variant of the Spectre attack on Intel CPUs can be used to crack open Intel's secure enclaves to view their memory.

The so-called SgxPectre side-channel attack affects programs with sensitive components protected by Intel's SGX or Software Guard Extensions enclaves.

SGX is available in newer Intel Core chips and allows developers to selectively isolate sensitive application code and data to run in their own execution environment.

This enclave is created by the CPU and allows sensitive parts of an application to run in its own memory region inside the enclave where it's protected from the system software, including hypervisors and the operating system.

Microsoft also recently began supporting SGX in Azure allowing developers to protect data from the threat of rogue staff at its data centers.

As researchers from Ohio State University explain in a paper detailing SgxPectre, the Meltdown and Spectre attacks on CPUs raise questions over SGX's resilience to them. It turns out that it's not resilient and it's just as difficult to fix.

An attacker using SgxPectre can "completely compromise the confidentiality of SGX enclaves" and learn the content of the enclave's memory.

The researchers explain the attack "exploits the race condition between the injected, speculatively executed memory references, which lead to side-channel observable cache traces, and the latency of the branch resolution".

The attack focuses on two hardware features of Intel CPUs that are designed to enhance a chip's performance through speculative execution.

These include branch prediction of enclave code, which can be manipulated by code outside the enclave, and implicit caching of memory caused by speculatively executed instructions.

"The branch prediction units used in the enclave mode for predicting branch targets are not thoroughly cleaned upon enclave entrance. Therefore, code outside the targeted enclave (either running in the unprotected memory region or in another enclave) can manipulate the targets of the branch prediction inside the targeted enclave," the researchers explain.

"Implicit caching caused by speculatively executed instructions are not properly rolled back after these instructions are discarded, which means the speculatively executed instructions, though never committed to memory, may lead to cache state changes that are observable by the adversary."

To exploit this weakness, the enclave code needs to display certain code patterns. However, these code patterns are present in Intel's software developer kit (SDK) for building SGX programs. Rust-SGX and Graphene-SGX are vulnerable for the same reason. In other words, any code built with the SDKs will be affected.

The attack can be mitigated by Indirect Branch Restricted Speculation (IBRS), one of the fixes Intel shipped in its microcode updates for Spectre Variant 2.

However, since microcode updates can be reverted, developers relying on SGX in the cloud would need to verify the CPU security version number during remote attestation.

The researchers have released a vulnerability scanning tool for finding vulnerable code patterns in enclave programs, and plan to open-source SgxPectre exploits later.

The issues were reported to Intel before the paper was published.

Intel contacted ZDNet to say its mitigations for Spectre and Meltdown combined with an update for SGX SDK due on March 16 will prevent the SgxPectre attack. Here's its full statement:

We are aware of the research paper from Ohio State and have previously provided information and guidance online about how Intel SGX may be impacted by the side channel analysis vulnerabilities. We anticipate that the existing mitigations for Spectre and Meltdown, in conjunction with an updated software development toolkit for SGX application providers -- which we plan to begin making available on March 16th -- will be effective against the methods described in that research. We recommend customers make sure they are always using the most recent version of the toolkit.



No comments:

Post a Comment