OECD bibliometric indicators: Selected highlights, April 2024
SnakeGX (short version)
1. SnakeGX: a sneaky attack
against SGX Enclaves
Flavio Toffalini - Singapore University of Technology and Design
Mariano Graziano - Cisco Systems, Inc.
Mauro Conti - University of Padua
Jianying Zhou - Singapore University of Technology and Design
ACNS - June 21-24, 2021
1
3. SGX introduction
3
User-space
Kernel-space
Enclave
Intel Software Guard eXtention (SGX)
- Enclaves: isolated memory regions in
user-space
- Enclaves cannot interact with ring-0
software (i.e., no syscall)
- Enclaves can write/read in user-space
- User- and kernel-space cannot write/read
the enclave space
HOW IS THIS ENFORCED?
CPU/MMU/Microcode checks.
OS-independent design.
4. Problem description - SGX issues
4
User-space
Kernel-space
SGX assumes everything outside an Enclave is
malicious (e.g., the OS) [1]
Usually good, however, the OS must trust an
enclave contain bening software
A code-reuse attack could alter the enclave logic,
without breaking the isolation [2,3,4,5]
The OS is not aware of the attack
Enclave
?
? ?
[1] Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface (SIGARCH 2013)
[2] Hacking in Darkness: Return-oriented Programming against Secure Enclaves (Usenix 2017)
[3] The Guard's Dilemma: Efficient Code-Reuse Attacks Against Intel SGX (Usenix 2018)
[4] A Tale of Two Worlds: Assessing the Vulnerability of Enclave Shielding Runtimes (CCS 2019)
[5] Faulty Point Unit: ABI Poisoning Attacks on Intel SGX (ACSAC 2020)
5. Current memory attacks
State-of-the-art attacks:
5
Forces the enclave to crash and
restart multiple times to “guess”
the correct attack
Dark-ROP
(Usenix 2017)
Relies on code patterns, no
need to crash the enclave
It leaves many structures in
memory
Guard’s Dilemma
(Usenix 2018)
Introduces a new and unexpected
enclave in the system that attracts
the intention of the analyst
SGX-ROP
(Dimva 2019)
// not exactly an attack
Too noisy Too many
traces
Add unexpected
enclaves
6. SnakeGX
Research question:
Is it possible to attack an SGX enclave without being detected by the host OS?
Our proposal: a framework to implant a backdoor in legitimate SGX enclaves
How?
1) Exploiting SGX isolation to avoid memory-inspection
2) Leaving less traces as possible
6
7. Application
SnakeGX - The plan!
Install a backdoor in the victim enclave => add a malicious secure function
Enclave
Secure Function 1
Secure Function N
...
Backdoor
Safe code
Attacker
7
8. SnakeGX - The plan!
Properties:
- Persistent: remains inside the enclave
- Stateful: it saves date and takes decision
- Interactive: can invoke syscalls
Note: The backdoor is entirely composed by code-reuse
techniques (e.g., ROP-chains)
8
User-space
Kernel-space
Enclave
Backdoor
➊
➌
X := 10
➋
➊
➌
➋
More technical details in the paper..
10. SnakeGX - Advantages
10
User-space
Enclave
Backdoor
Attacker ORET
- No need to repeat the attack from scratch
- An analyst can found only the trigger, which
footprint is minimal
- Enclave interaction through valid APIs
Kernel-space
More technical details in the paper..
11. The Evaluation
- Use Case: StealthDB
- Trace measurements and comparison with SotA
11
12. Use Case: StealthDB
StealthDB1
is a PostgreSQL extension to perform homomorphic-like encryption by using
SGX enclaves
Application
Enclave
Secure Function
Backdoor
Safe code
Attacker
P_Key (AES key)
backdoor() {
if (P_Key is changed)
exfiltrate(P_Key)
}
ORET
ECALL
12
[1] https://github.com/cryptograph/stealthdb/
13. Use Case: StealthDB
13
Analysis Payload
P1
: checks status and in case
exfiltrates P_Key
Oc
: write P_Key on a socket
P2
: restores the payload for a next
execution
Application
Enclave
P1
Attacker
P_Key (AES key)
P1
() {
if (P_Key is changed)
exfiltrate(P_Key)
}
ORET
OC
P2
ORET
socket
16. Conclusion
Before
- Current SGX malware introduces unexpected enclaves in the system
- Current one-shot-attacks need to repeat the attack(and leave traces in memory)
Now
- Infecting legitimate enclaves (no new enclaves)
- SnakeGX hides most of the logic inside the enclave (more challenging to detect)
16