Opened 3 years ago

Last modified 3 years ago

#21114 new defect

Evaluate SGX impact on exploitation

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Threat model:
1 adversary has access to Intel backdoors to put own versions of Intel trusted SGX service enclaves.
2 adversary uses the most sophisticated exploits they have against the user
3 adversary is not willing to use that exploits if they can be investigated and disclosed

so

1 We shouldn't put whole TorBrowser into SGX enclave. This will make exploits unauditable.
2 Enclaves are restricted to ring 3 but they can use syscalls. The common attack scenario is hacking usermode process first and then escalating the privileges. For privilege escalation phase an adversary can setup an enclave and upload an exploit there after remote attestation, which will make the exploit unanalyzable. So we need a way to reliably disable SGX on the systems TorBrowser is executed.

Child Tickets

Change History (2)

comment:1 in reply to:  description Changed 3 years ago by cypherpunks

Replying to cypherpunks:
Threat model:
1 adversary has access to Intel backdoors to put own versions of Intel trusted SGX service enclaves.
2 adversary uses the most sophisticated exploits they have against the user
3 adversary is not willing to use the most sophisticated exploits if they can be investigated and disclosed. In this case it will spare them for high-value targets. Otherwise it will use them on everybody.

so

1 We shouldn't put whole TorBrowser into SGX enclave. This will make exploits unauditable.
2 Enclaves are restricted to ring 3 but they can use syscalls. The common attack scenario is hacking usermode process first and then escalating the privileges. For privilege escalation phase an adversary can setup an enclave and upload an exploit there after remote attestation, which will make the exploit unanalyzable. So we need a way to reliably disable SGX on the systems TorBrowser is executed.

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:2 Changed 3 years ago by cypherpunks

There is no way to disable SGX enclaves completely. Even on hardware without SGX support, there is something similar on hardware with Intel TXT support called memory curtaining (though it's not quite as comprehensive as an SGX enclave, e.g. you can still use probe mode when in memory curtaining context).

Anyway, your threat model falls apart at part 3. There is no way that an exploit can be served in a way that is completely undetectable, because it will still need to go through the network, and through processes/buffers outside the enclave to get there. All it could accomplish is being harder to audit, by making debugging live code paths harder. Just a few ways a program could already make itself insanely difficult to audit, other than SGX:

  • TXT memory curtaining
  • Bispe (TRESOR-based bytecode interpreter)
  • Page-fault based bytecode interpreter
  • Offloading execution to other processors (GPUs, NICs, etc)

Hell would freeze over before it would be possible to put the entirety of Firefox in an SGX enclave anyway. Even putting a basic program into an enclave requires heavily rewriting it to support the necessary I/O with the rest of the system.

Btw, enclaves cannot make syscalls. They cannot even use all instructions available to ring 3.

This is a rather poorly thought out ticket due to scope and threat model. I vote to close it.

Note: See TracTickets for help on using tickets.