3 ms·

There was a CTF this weekend (UTCTF) featuring a task to exploit a program running in a secure SGX enclave. As part of solving that task I spent some time looki

There was a CTF this weekend (UTCTF) featuring a task to exploit a program running in a secure SGX enclave. As part of solving that task I spent some time looking into the design of SGX, and I gotta say it doesn’t sound promising. The basic idea is to be able to run code on an Intel processor that cannot be tampered with or even examined by any other part of the system, including the OS, hypervisors, etc. The entire code and data segment of this program runs in its own world, the “secure enclave”, in user mode (ring 3). The attack model is that every piece of software executing on the CPU (user code, OS code, hypervisors) and every bit of hardware outside the CPU (network interfaces, hardware buses, memory interfaces) could be compromised and attempting to leak data from your Secure Enclave, and the enclave code/data should still remain tamper proof and unreadable. The SGX implementation even includes an attestation system, using a trusted server operated by Intel, which will attempt to verify that the CPU itself is not compromised. The entire thing depends on a lot of cryptography. Sealing keys to encrypt data that will be persisted to disk from the enclave. Memory protection keys to encrypt everything going to RAM. Page encryption keys to encrypt any memory that the OS tries to page out. Attestation keys to cryptographically verify that the CPU measured itself to be OK. Cryptographic signatures to validate the initial enclave code and data to protect against tampering of the initial state. Session keys to protect the enclave’s communication with whatever application server is providing the code/data for the enclave’s computation. The OS and even the ring 3 application hosting the enclave have a MITM position on absolutely everything the enclave does, so the disclosure of just one of these keys breaks the security of the whole system. I am not surprised at all that SGX wound up being vulnerable to a low-level CPU attack. The attack surface is way too big and there are too many points of failure.

warkdarrior 7y ago
> I am not surprised at all that SGX wound up being vulnerable to a low-level CPU attack. Most secure systems assume that the CPU is functioning correctly. It is not clear that you can do anything securely if the CPU is buggy.
- ngneer 7y ago
  What is correctly? You have to understand that SGX was built on an existing infrastructure, without rebuilding the chip. Intel architects ignored side channels for years. So the security specification was being met, except it had ignored a crucial threat. Small comfort. My point is that "correctly" for security can only be defined in the context of a threat model. If the model is incomplete, then you are exposed. I am not aware of a complete threat model for TEE design. And the reason is clear. The threats develop over time, springing into existence as an emergent property of complex designs rewarded by a market that is not keen on incentivizing secure design.
  - warkdarrior 7y ago
    The Intel instruction specification details which access control checks are performed when executing instructions. In most of the speculative execution bugs, the Intel implementors decided to skip those checks for performance reasons. Note that this is a implementation correctness issue, not a security issue (which is defined only for a threat model). The SGX design was created on top of the instruction specification, not on top of specific buggy processors. Hence the vulnerability! The threat model for SGX did not consider incorrect processor implementation.
    - saagarjha 7y ago
      > The Intel instruction specification details which access control checks are performed when executing instructions. In most of the speculative execution bugs, the Intel implementors decided to skip those checks for performance reasons. Note that this is a implementation correctness issue, not a security issue (which is defined only for a threat model). Note that the access checks are only bypassed when executing speculatively, because they get reordered to occur before the checks take place. It's not that the checks aren't there; it's that they're too late and this allows for tainting micro-architectural buffers with the side effects of the invalid loads.
    - ngneer 7y ago
      I think we are on the same page. I was referring to the specific SGX implementation that relied on existing processor infrastructure, and you are making the argument that no system can be secure that is built on a faulty implementation. No amount of threat modeling will help you if an implementation does not perform its function. All threat models are built under the implicit assumption that the implementation they will help derive will be correct. The threat model helps to answer the question of which function should be realized. Whether that function is in fact realized or not is a different matter. With the speculative execution bugs, the function being realized unintentionally deviated from the specified access checks.
SlowRobotAhead 7y ago
> The attack surface is way too big and there are too many points of failure. First impression, but is it a ridiculous notion to assume that loading code into the secure area wouldn’t be used by malware? Like if you were trying to avoid detection for the rest of the system that doesn’t seem like a great place to do it?
- saagarjha 7y ago
  You'd still need some code in the userspace/kernel code to call it, though.

warkdarrior 7y ago

> I am not surprised at all that SGX wound up being vulnerable to a low-level CPU attack. Most secure systems assume that the CPU is functioning correctly. It is not clear that you can do anything securely if the CPU is buggy.

ngneer 7y ago
What is correctly? You have to understand that SGX was built on an existing infrastructure, without rebuilding the chip. Intel architects ignored side channels for years. So the security specification was being met, except it had ignored a crucial threat. Small comfort. My point is that "correctly" for security can only be defined in the context of a threat model. If the model is incomplete, then you are exposed. I am not aware of a complete threat model for TEE design. And the reason is clear. The threats develop over time, springing into existence as an emergent property of complex designs rewarded by a market that is not keen on incentivizing secure design.
- warkdarrior 7y ago
  The Intel instruction specification details which access control checks are performed when executing instructions. In most of the speculative execution bugs, the Intel implementors decided to skip those checks for performance reasons. Note that this is a implementation correctness issue, not a security issue (which is defined only for a threat model). The SGX design was created on top of the instruction specification, not on top of specific buggy processors. Hence the vulnerability! The threat model for SGX did not consider incorrect processor implementation.
  - saagarjha 7y ago
    > The Intel instruction specification details which access control checks are performed when executing instructions. In most of the speculative execution bugs, the Intel implementors decided to skip those checks for performance reasons. Note that this is a implementation correctness issue, not a security issue (which is defined only for a threat model). Note that the access checks are only bypassed when executing speculatively, because they get reordered to occur before the checks take place. It's not that the checks aren't there; it's that they're too late and this allows for tainting micro-architectural buffers with the side effects of the invalid loads.
  - ngneer 7y ago
    I think we are on the same page. I was referring to the specific SGX implementation that relied on existing processor infrastructure, and you are making the argument that no system can be secure that is built on a faulty implementation. No amount of threat modeling will help you if an implementation does not perform its function. All threat models are built under the implicit assumption that the implementation they will help derive will be correct. The threat model helps to answer the question of which function should be realized. Whether that function is in fact realized or not is a different matter. With the speculative execution bugs, the function being realized unintentionally deviated from the specified access checks.

SlowRobotAhead 7y ago

> The attack surface is way too big and there are too many points of failure. First impression, but is it a ridiculous notion to assume that loading code into the secure area wouldn’t be used by malware? Like if you were trying to avoid detection for the rest of the system that doesn’t seem like a great place to do it?

saagarjha 7y ago
You'd still need some code in the userspace/kernel code to call it, though.