Defending against dynamically loading or injecting leaking code into W+X page about elf-respect HOT 8 CLOSED

@heartever 师兄 said that we may cannot check whether a program have this kind of vulnerability. Or, we may need to depend on the features of sgxv2 to check it. In other words, it sounds that sgxv1 is very difficult to prevent this attack. In sgxv2, our binary loader can modify the read, write, and execute attributes of pages, and change the attributes of pages after the load is completed.

from elf-respect.

I think we need to first determine the threat model of how attacker can leak information.

Do they leak information by calling data leakage sensitive functions such as open, write, and mprotect? If it is the case, we can just instrument the libc to detect whether such leakage sensitive functions are called or not.

What are the common data leakage methods we should consider and are there any existing papers for references?

from elf-respect.

Inside enclaves, no system call is allowed. So we do not consider leakage through open, write etc.

We care about explicit data leakage through memory access instruction, such as using MOV to write a secret value to an external address.

One viable way is to use SGXv2 support to prevent runtime code leakage, however there exists better solutions. Please look into the "SGX-Shield" paper (SEC 4.D Software DEP in Enclaves): it implements a dynamic loader inside the enclave and the loader checks the memory address during runtime.

SGX-Shield does not prevent the attack which redirects the control flow.

from elf-respect.

Inside enclaves, no system call is allowed. So we do not consider leakage through open, write etc.

Are all system calls not allowed or a subset of the system calls not allowed? If all system calls are not allowed, then how programs running in SGX allocate memory? For example, malloc in the end will call system call brk to allocate new space.

I guess SGX provides a set of interface that allows programs running in SGX to do essential operations such as allocating memory. Is there such a list of operations allowed by SGX?

We care about explicit data leakage through memory access instruction, such as using MOV to write a secret value to an external address.

I am sorry for my lack of understanding of SGX. I thought SGX only allows accesses within the enclave. How can a program running in SGX using mov to write a value to an external address?

One viable way is to use SGXv2 support to prevent runtime code leakage, however there exists better solutions. Please look into the "SGX-Shield" paper (SEC 4.D Software DEP in Enclaves): it implements a dynamic loader inside the enclave and the loader checks the memory address during runtime.

I will read the paper to get more background information.

SGX-Shield does not prevent the attack which redirects the control flow.

from elf-respect.

No systems calls are allowed in SGX. Memories such as heap/stack are allocated when the SGX enclave is created. Libc is re-written in SGX so that when malloc is called, memory is allocated from SGX heap region.

Code inside SGX can access addresses inside SGX enclave and outside enclave directly. They are in the same address space and the accesses are not blocked by memory controller. (Accesses from outside enclave to inside enclave are blocked.)

from elf-respect.

No systems calls are allowed in SGX. Memories such as heap/stack are allocated when the SGX enclave is created. Libc is re-written in SGX so that when malloc is called, memory is allocated from SGX heap region.

I see. In enclave, are signals delivered as usual or not? Redirecting control flow through signal handler is a common method for hiding code from static analysis.

Code inside SGX can access addresses inside SGX enclave and outside enclave directly. They are in the same address space and the accesses are not blocked by memory controller. (Accesses from outside enclave to inside enclave are blocked.)

Since code inside SGX can directly accesses memory outside SGX, do we need to distinguish benign memory write from inside SGX to outside SGX from data leaking memory write from inside SGX to outside SGX?

from elf-respect.

No systems calls are allowed in SGX. Memories such as heap/stack are allocated when the SGX enclave is created. Libc is re-written in SGX so that when malloc is called, memory is allocated from SGX heap region.

I see. In enclave, are signals delivered as usual or not? Redirecting control flow through signal handler is a common method for hiding code from static analysis.

I believe the attempts to redirect the control flows could be prevented by TSX. We will implement a partial-CFI with TSX. The partial-CFI can be seamlessly integrated with the memory address checking.

Code inside SGX can access addresses inside SGX enclave and outside enclave directly. They are in the same address space and the accesses are not blocked by memory controller. (Accesses from outside enclave to inside enclave are blocked.)

Since code inside SGX can directly accesses memory outside SGX, do we need to distinguish benign memory write from inside SGX to outside SGX from data leaking memory write from inside SGX to outside SGX?

This could be an issue. Our design blocks all external memory writing.

from elf-respect.

This could be an issue. Our design blocks all external memory writing.

Is blocking all external memory writes a realistic design? If we block all external memory writing, how a benign application communicates the results calculated within SGX to outside SGX or to the client?

I saw that when the application exits SGX, the register state of SGX is also saved and cleared. If we in addition block all extern memory writes, then how SGX communicates with host and client?

from elf-respect.