SnakeGX: A Sneaky Attack Against SGX Enclaves

Abstract

Intel Software Guard eXtension (SGX) is a technology to create enclaves (i.e., trusted memory regions) hardware isolated from a compromised operating system. Recently, researchers showed that unprivileged adversaries can mount code-reuse attacks to steal secrets from enclaves. However, modern operating systems can use memory-forensic techniques to detect their traces. To this end, we propose SnakeGX, an approach that allows stealthier attacks with a minimal footprint; SnakeGX is a framework to implant a persistent backdoor in legitimate enclaves. Our solution encompasses a new architecture specifically designed to overcome the challenges SGX environments pose, while preserving their integrity and functionality. We thoroughly evaluate SnakeGX against StealthDB, which demonstrates the feasibility of our approach.

Appendices

A Code-Reuse Technique

To show the feasibility of SnakeGX, we choose for our proof-of-concept the technique described by Biondo et al. [12]. This means that SnakeGX uses ROP. However, as stated in Sect. 3, SnakeGX does not rely on a specific technique, but it does require one to control its behavior. Moreover, we adapted their approach to work on the Intel SGX SDK newer versions.

In the original approach, the authors exploited asm_oret() and continue_execution() functions. More precisely, they crafted a set of fake frame in order to create a loop between these functions. In the x64 architecture, the first four function parameters are passed by registers. Therefore, the authors used asm_oret() for setting continue_execution() registers pointing to a controlled structure. However, as also Biondo underlined, it is more complicated to use asm_oret() for SDK 2.0. This is why in our approach we substituted asm_oret() with a glue gadget. This might be any gadget that sets the input register for the continue_execution() function. Since we developed our proof-of-concept for Linux 64bit, continue_execution() expects the first argument (i.e., a sgx_exception_info_t address) in the rdi register. This is achievable by using a classic pop rdi gadget. Windows, instead, follows a different calling convention and continue_execution() expects an ocall_context address shifted by 8 byes in the rcx register. Therefore we used a pop rcx as a glue gadget. In our evaluation, we found pop rdi and pop rcx gadgets in the Intel SGX SDK version for Linux and Windows, respectively.

Fig. 6.

Chain used in the proof-of-concept of SnakeGX.

Figure 6 describes our code-reuse technique. The attacker crafts a fake stack that can reside inside or outside the enclave, we used both approaches. The fake stack is composed by frames, one of which contains in order: (i) a glue gadget address, (ii) a fake sgx_exception_info_t address, (iii) the continue_execution() address. Once the first glue gadget is triggered, it will set rdi (or rcx in Windows) register pointing to the fake sgx_exception_info_t structure. Then, the continue_execution() will set registers according to sgx_exception_info_t and it will also pivot to the actual gadget. Since continue_execution() allows us to control all general registers, we can easily invoke another function instead of a simple gadget (e.g., memcpy in Frame 1). Finally, the gadget will return at the beginning of the next frame. At this point, the CPU will trigger a new glue gadget and the attack continues.

Our technique is more flexible compared to the one described by Biondo. By using a glue gadget, we can easily drive continue_execution() without relying on other SDK functions that might change in future versions.

B Conditional Chain

Conditional ROP-chain, the chain is triggered by using sgx_exception_info_t structure that configures the initial registers (see Appendix A). The SP register is perturbed if the value of &lastKey differs from the value of &key in order to pivot a true or a false ROP-chain, respectively.

C Context-Switch Chain

Details of the sgx_exception_info_t structures used to leak the key and to switch outside the enclave. The structures are used according to the techniques described in Appendix A.

Details of the outside ROP-chains used to resume payload inside the enclave.

D Preliminary Analysis of Assumptions

Table 3 contains a list of 27 stand-alone SGX projects extracted from [9]. For each project, we indicate their category, if it used the Intel SGX SDK, the number of trusted threads for each enclave of the project, and a note. We also list details for each enclave, if the project contains many. We counted 24 out of 27 projects developed on top of Intel SGX SDK, two projects use alternative SDKs (i.e., Open Enclave SDK [28] and Graphene [43]), while one contains a simulated enclave. Among the projects based on the Intel SGX SDK, we counted a total of 31 enclaves, and 24 out of 31 are multi-threading ($77\%$).

Table 3. SGX open-source projects extracted from [9].