stanplatinum / elf-respect Goto Github PK

Dyninst can instrument every memory write. However, we need to determine whether a particular memory write is leaking user data.

We discuss the rules of determining whether a memory writes leaks data in this issue.

One of the first step of this research effort is to determine a set of software we want to experiment with.

We discuss what programs we want to experiment in this issue.

To check whether a binary is rewritten as we demand, we need to use the binary analysis components of Dyninst, including SymtabAPI, InstructionAPI, and ParseAPI.

We discuss whether these Dyninst components can be run in SGX. If not, how to make them running in SGX.

@heartever 师兄's words reminds me that an attacker may commit a control flow hijack to bypass our data-leakage checking. Our tentative solution is to use Intel TSX (HLE) feature that makes our checker (code for data-leakage check) a transaction. I think the idea is great and it's easy to implement. However, it seems that the introduced performance overhead is not negligible...

Static analysis may not be able to defend against this attack: an attacker loads code, which leaks information, into a location and executes it at runtime.
Since SGX don't support JIT compile nor system call, the attacker may not loads code at runtime. But it seems that SGX applications can be loaded dynamically, and it has a mechanism to modify the properties of pages.
So, if this kind attack exists, how we handle it?

The rewritten binary currently needs dyninstAPI_RT.so. So we need to check whether dyninstAPI_RT.so can be executed in SGX. If not, how to deal with it.

We could take some actions to add some side/covert-channel-free proofs with the target program, and verify them inside the enclave.

To defend against covert channel, we could eliminate all the dependencies between input data and service code's control flow.

To defend some certain type of side channels, we could use some specific policies to confine the target program.