Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Vulnerabilities in SGX trusted enclave_entry procedure #28
I identified several security-critical vulnerabilities in Graphene's trusted runtime for SGX enclaves. It should be noted that the containing host application, including the unprotected Graphene runtime, is completely untrusted in the SGX attacker model.
As a general rule, the trusted intra-enclave runtime should properly check all arguments/return values passed from the untrusted runtime. This is currently not the case in at least the following places:
.Lhandle_ecall: lea ecall_table(%rip), %rbx mov (%rbx,%rdi,8), %rbx ... call *%rbx
An attacker controlling the unprotected application can redirect control flow to non-entry functions by abusing intra-enclave function pointers. She could even jump to arbitrary in-enclave code by over/underflowing the ecall_table lookup to unprotected memory (or enclave memory that holds user input).
cmp $RETURN_FROM_OCALL, %rdi je .Lreturn_from_ocall ... .Lreturn_from_ocall mov %gs:SGX_LAST_STACK, %rsp popfq ... ret
An attacker can abuse this to initialize the in-enclave stack pointer of a newly started thread with the value of the last ocall. The memory content at these locations determine register values, and ultimately control flow.
I included a proof-of-concept exploit at https://github.com/jovanbulck/graphene.
To demonstrate the danger of allowing arbitrary non-entry code execution, I wrote an elementary application that decides access to an
I also included a proof-of-concept exploit that redirects control flow to an arbitrary non-entry function of the trusted runtime by abusing the argument of
It should be clear from the above explanation and the exploit that Graphene's trusted runtime should restrict enclave entry to a few well-defined entry points. I did not write a patch since it is not yet entirely clear what the best solution would be:
<jo.vanbulck at cs.kuleuven dot be>