This article is more than 1 year old
Intel SGX 'safe' room easily trashed by white-hat hacking marauders: Enclave malware demo'd
Handy for smuggling expensive zero-days onto targets and executing them, without antivirus realizing
Updated Security researchers have found that Intel's Software Guard Extensions (SGX) don't live up to their name. In fact, we're told, they can be used to hide pieces of malware that silently masquerade as normal applications.
SGX is a set of processor instructions and features for creating a secure enclave in which code can be executed without scrutiny or interference from any other software – not even the operating system nor hypervisor can look in. It's aimed at processing financial transactions, performing anti-piracy decryption of protected Hollywood movies, and similar cryptography in private away from prying eyes.
That's the theory. However, boffins – some of whom helped expose the Spectre-Meltdown processor flaws last year – think they have cracked open some of the security defenses, by leveraging the age-old technique of return-oriented programming.
Return-oriented programming (ROP) involves overwriting a thread's stack to, rather than have the application work as normal, make it carry out malicious operations instead. This is done by stringing together clumps of unrelated memory-resident instructions, called gadgets, to manipulate the operation of the software. It's a bit like carjacking someone using the tire iron in the vehicle's trunk (or boot for our UK readers).
You change the return addresses in the stack so that the code jumps not back to where it should be after a routine, but to small sections of other code, followed by another section, then another, building up a patchwork of instructions that tell the program to do something else than it should, like leak or change data.
In a paper scheduled for publication on Tuesday, "Practical Enclave Malware with Intel SGX," brainiacs at the Graz University of Technology in Austria describe a technique to bypass various security technologies, such as ASLR, and execute arbitrary code that can steal information or conduct denial-of-service attacks, all via SGX and ROP.
Summary: Take an exploit, encrypt it, put it in an SGX enclave, decrypt only after remote trigger signal, run exploit via ROP chain on host app, remove traces of ROP immediately + continue regular host execution, repeat on other victims.— Daniel Gruss (@lavados) February 12, 2019
Enclaves have to talk to the outside world via their assigned host application, yet the team's SGX-ROP approach allows the enclave code to meddle with the underlying system by hijacking the host process using ROP.
In effect, malware in the enclave is hidden from view, out of sight of antivirus and other security packages, but it can potentially do what it likes to the environment around it, via its hijacked host, when activated. This also means the enclave can keep its vulnerability exploit code secret by encrypting it and privately decrypting and executing it as necessary, when it gets a signal to attack.
"We demonstrate that instead of protecting users from harm, SGX currently poses a security threat, facilitating so-called super-malware with ready-to-hit exploits," explain co-authors Michael Schwarz, Samuel Weiser, and Daniel Gruss in their paper.
Spectre haunts Intel's SGX defense: CPU flaws can be exploited to snoop on enclavesREAD MORE
The trio say that security experts tend to discount attacks involving enclaves because these locked-down code spaces are more constrained than normal system processes – enclaves can only issue system calls, to interact with the operating system, through their host application, and they can't handle I/O operations directly. That should stop bad code within an enclave from reaching the outside world.
Nonetheless, the Graz group found a viable way to bypass Intel's enclave launch process and obtain signing keys, particularly now that SGXv2 provides a way to remove Intel as an intermediary for enclave signing. This means a malicious enclave can work around its restrictions – no syscalls nor knowledge of host application memory – to run arbitrary code as the host process, using ROP, and parade around the computer rather than staying confined to its shoe box.
It is, admittedly, a convoluted technique – compared to classic Windows escalation-of-privilege attacks – yet it's a fascinating approach.
"The enclave has to run locally, but the trigger signal to run the exploit comes from a remote adversary in the scenarios we describe," said Gruss in an email to The Register.
"So you can deploy your exploit (maybe a super expensive zero-day exploit) on all devices via an enclave and no one could tell. Then send the trigger signal when you like and to whom you like and run the exploit."
"However, it could also be an enclave with a bug which can be exploited remotely," Gruss added. "That would have the same result. Arbitrary code execution in an enclave means untraceable arbitrary code execution on the device. An attacker can do anything then."
Attackers TAP resources
The attack relies on the Transactional Synchronization eXtensions (TSX) in modern Intel processors, in conjunction with a novel technique called TSX-based Address Probing (TAP). TAP involves using TSX to determine if a virtual address is accessible by the current process, the researchers explain. And this exploration of memory is invisible to the operating system because that's how secure enclaves are designed.
"We have been working with TSX since quite a while," said Gruss. "It has several interesting properties that we've exploited in the past years. If the processor has TSX support (many don't have TSX support) then the attack can be run just like that, no special preparations required."
He added that the TSX primitive is also interesting in contexts unrelated to SGX because it can be used an an "egg hunter" for scanning the address space for injected shell code (in a system supporting TSX).
TAP's goal is to find code that resides in memory – code gadgets – so they can be chained together for an ROP-style code-reuse attack. But to conduct an SGX-ROP attack, the attacker has to have access to writeable host memory, to store the fake stack frame and attack payload. Since the secure enclave can't allocate host application memory, TAP is used to spot accessible memory.
Boffin suggests Trappist monk approach for Spectre-Meltdown-grade processor flaws, other security holes: Don't say anything public – zip itREAD MORE
To pull that off, the researchers developed a fault-resistant write primitive, Checking Located Addresses for Writability (CLAW). To determine whether a memory page is writable, CLAW wraps the write instruction for the target page in a TSX transaction and aborts it after the write. The writability of the page can then be deduced by the return value of the transaction.
"With SGX-ROP, we bypassed ASLR, stack canaries, and address sanitizer, to run ROP gadgets in the host context enabling practical enclave malware," the researchers claim, noting that the entire exploit process can be accomplished in about 20 seconds.
Gruss said he and his colleagues are looking into techniques like sandboxing to make SGX better. But as with the Spectre and Meltdown fixes, the cost could be paid in processor speed.
"We are working on mitigations, some of which trade performance for security on commodity systems, others require hardware changes but do not cost any performance," he said.
The Register asked Intel if it was aware of the researchers' work prior to publication. An Intel spokesperson didn't have an immediate response, but we'll let you know if the company has something to add. ®
Updated to add
In a statement emailed to The Register, an Intel spokesperson said:
Intel is aware of this research which is based upon assumptions that are outside the threat model for Intel SGX. The value of Intel SGX is to execute code in a protected enclave; however, Intel SGX does not guarantee that the code executed in the enclave is from a trusted source. In all cases, we recommend utilizing programs, files, apps, and plugins from trusted sources. Protecting customers continues to be a critical priority for us and we would like to thank Michael Schwarz, Samuel Weiser, and Daniel Grus for their ongoing research and for working with Intel on coordinated vulnerability disclosure.