security issues due to prevalent use of [user_check] about talos

[plaublin]

Hello

Thank you for raising this issue. Indeed some additional checks could be implemented to check the provenance of the pointers passed with [user_check].

[f0rki]

Hi everyone, Hi @plaublin,

I am an academic security researcher at University of Duisburg-Essen, working with (@ldavi and @Tcc100). During our research on SGX we also discovered the security issues mentioned in this issue. However, we took it one step further and constructed a proof-of-concept exploit that achieves arbitrary code execution inside of the TaLoS SGX enclave, effectively bypassing any protections offered by SGX.

Indeed some additional checks could be implemented to check the provenance of the pointers passed with [user_check].

It is not easy to add sufficient checks to pointers passed with [user_check]. For example, a check for inside/outside enclave memory can often be bypassed by an attacker.

In our experience the best way to fix this is to avoid passing pointers to enclave memory at all and otherwise rely on the SGX SDK provided [in, out] attributes.
Our suggestion is to replace pointers to enclave memory with simple integer identifiers, which are then translated into pointers using e.g., a hashmap or array lookup at the start of the ECALLs.

If you prefer I can contact you privately (e.g., via E-Mail) for details on our exploit and our recommendations on how to fix this issue.

[plaublin]

Hello

This is interesting. Would you have any reference to your proof of concept?

Replacing pointers with integer identifiers is what the shadow structures mechanism is doing: https://www.doc.ic.ac.uk/research/technicalreports/2017/DTRS17-5.pdf . We have used it for the SSL structure primarily, but it can be generalized to all of them.

Unfortunately I lack resources to quickly fix the issue... If you would happen to have pull requests I would be immensely grateful.

[f0rki]

Hi @plaublin, I'd rather discuss this privately. Can you contact me via email at michael.rodler (at) uni-due.de?

[f0rki]

For sake of completeness and since this probably won't get fixed any time soon, we published our PoC exploits (three variants) against this project: uni-due-syssec/teerex-exploits. Maybe this helps someone out there to create a pull request with fixes.