potential security issue: ecall_SSL_write using [user_check]

[jxjlearn]

TaLoS/src/talos/enclaveshim/enclave.edl

Line 87 in 43d5890

public int ecall_SSL_write([user_check] SSL *ssl,[user_check] const void *buf,int num);

This edl definition uses [user_check] for pointer argument "const void *buf". It introduces the vulnerability to allow attackers to retrieve the secret info inside enclave, because SGX boundary check has been skipped for this pointer.

Potential attack methodology: with help of another ecall function, ecall_SSL_read, one can pass a pointer pointing an address inside SGX enclave to ecall_SSL_write, then use ecall_SSL_read to read the content of enclave through SSL communication.

The simple fix will be to change edl attribute for "const void *buf" in ecall_SSL_write from [user_check] to [in], or to add boundary-checking code in the applications, such as using SGX-provided function "sgx_is_outside_enclave" like here.

Please feel free to contact me if you want to discuss this issue, and I can explain it more by demonstrating a POC exploring this vulnerability.

[plaublin]

Hi

Thank you for reporting this issue. There should have been a check using the sgx_is_outside_enclave function, as you describe.
I would be very interested by your proof of concept indeed. Could you please share it?

[jxjlearn]

Sure, I will share it with you soon.

[jxjlearn]

Sorry for the delayed response. Here is a brief description of this POC.
Two parties A and B are required to explore this potential vulnerability.

1. Build the SSL connection between A and B through TaLoS
2. A sends out the secret through
   SSL_write(ssl, (void *)secret_addr, size_of_secret);
3. B receives the secret through
   secret = SSL_read(ssl, rcvBuff, size_of_secret);

Assume we can acquire the address inside SGX enclave holding the secret through other means, and already assign it to "uint64_t secret_addr". But we can also scan the enclave address with this method.