Introduction to SGX and potential attack method

The Overview of SGX

What is the SGX?

With more and more attack on systems and bigger danger inside the internet. We get a new technology which named The Security Guard Extensions (The SGX). Actually the SGX aimed to separate the whole applications to two parts: secure part and unsecure part. The secure part named enclave. Which is stored in protected memory. Between the enclave and application, there is an interface is implemented. Which is consists of e-calls and o-calls. The e-calls are inside the enclave for calling to the unsecured code. The o-calls are located in the unsecured code for collecting data inside the enclave. The enclave is totally protected which means any access from external are not allowed. Only when the untrusted part of application call the trusted function then the code inside the enclave can see the data. When it returns, the enclave data are still stays in safe memory.

figure.1

Actually while the application’s host in process, the secure execution is happening too. The application has its own data, code and enclave. The enclave also contains its own data and code. The enclave can access the applications’ memory but the application are not allowed to access the enclave’s protected memory.

figure.2

Let’s talk about the protected memory

We said that the enclave code and data are stored in a protected memory. This area called Enclave Page Cache (EPC). The EPC is encrypted through the Memory Encryption Engine (MEE). So outside the application, if user want to access the data, they can only get the encrypted data. The pages can only be read inside the physical processor core.

So how to use the enclave?

The entry and the exit:

When we want to get access to the enclave. We can use the EENTER instruction which move the control from application to a pre-determined location inside the enclave. Once the EENTRY instruction is executed, the CPU will try to save the application context. Then the processor is put in enclave mode. As for the exit way, we can use the EEXIT instruction. Which will put process back in its original mode. When the EEXIT instruction is executed, the processor will be put in a normal mode.

figure.3

The ERESUME:

Once the program encountered a interruptions and exception. How can the SGX deal with it?

The interruptions and exception result in the Asynchronous Enclave Exit (AEX). Then a handler in this application can decide whether to resume or not resume the enclave, by using the ERESUME instruction. When the AEX happened, the context of enclave are saved in SSA, the context of the application are stored too. Once the ERESUME instruction executed, The enclave’s context are restored.

The whole process is when the interruption happened in the process. The enclave’s context is saved, the application’s context is restored. The Asynchronous Enclave Pointer (AEP) execute ERESUME (if it decides to). The enclave context restored, then the execution resumed.

figure.4

The design of a SGX program.

First of all, we need to separate to two programs. One is trusted, other one is not. All the sensitive data need to be located in the enclave. In order to connect the two parts. The interface contains e-calls and o-calls need to be achieved. The interface is defined by its’ signature.

Now let’s implement it

At first we need to set up two projects for enclave and untrusted code. We can use the SGX SDK. Then we need to fill the EDL-file with the interface. Which are implemented inside the enclave and the application.

Inside the application we can enable the SGX through:

figure.5

Then we need to create a enclave. with signed library compiled from enclaves code:

figure.6

Inside the enclave we need to store the private key for signing and verification. This means all untrusted code cannot get access to data stored in enclaves. All this function can get implemented with the SGX’s API.

We also need to implement five interfaces, named: esv_init, esv_sealkeys, esv_sign, esv_verify and esv_close. Two more interfaces in the applications enable it to read and write files.

The init:

Initialize almost everything needed to be used by the signing and verifying interface.

Signing:

Esv_sign receives a information to sign. The message passed to the sgx_ecdsa_sign, which sign the message and store it in the memory. And finally it stored into a file. The o-call use the esv_write_data to write the file.

figure.7

Verification:

Esv_verify gets the message and the signature. And verify them. The function return the results by using the e-calls. If the signature is valid, it will return zero.

figure.8

Key-Sealing

Esv_seal_keys saves the public key and private key which are stored in the enclave.

At the end of the application, we can also use the method sgx_destory_enclave to destroy the enclave and release the resource.

Is this SGX module really safe?

Nothing is really unbreakable.

Potential Attack Method

Cache Attacks on Intel SGX

Cache attack is proceeded at 10^th European Workshop on System Security. It is a kind of side channel attack. The attack method can be explained by Figure7. The author designed one application and pinned two kernels threads to two logical CPU cores. Considering the process share the same Physical CPU Core 0 and L1-Cache, this setup combines specific possibilities of root-level attacks within one single root-level cache-timing attack. The bad result is that the attacker will expose the secrets inside the enclave. RDPMC (Read Performance-Monitoring Counters) instruction is used to probe the cache line.

Figure.7: The attack setup consisting of one application with two threads pinned to two logical CPUs sharing the same physical core and L1-cash.

To realize the attack, such kind of settings should be ported to SGX enclaves, which means that the communication should happen outside the enclave. However, ECALLs (Enclave Calls) and OCALLs (Outside Calls) couldn’t use during the interactions with enclave, because they will evict the whole T4 table and prevent the probing detection in cache lines.
Therefore, the author uses shared memory to communication. Shared memory is used between SGX enclaves and unprotected code to increase the communication speed. Figure 8 shows how the communication happens between attack process and enclave. The particular flags are used to reduce the synchronisation effort.

Figure.8: Communication with shared memory

Two separate process for attack and victim is not workable, because when process switch occurs, CR3 register will be changed. It is used to update the Page Table (PT). The operation on CR3 will flush the Translation Lookaside Buffer (TLB) and L1-cache. That’s the reason why the author used the same process include two separate thread.

AsyncShock: Exploiting Synchronisation Bugs in Intel SGX Enclaves

This paper is published in 2016. The basic idea of attacking through AsyncShock is to establish the synchronization bugs inside an enclave. Synchronisation bugs are caused by the improper synchronised access of shared data by multiple threads. The attacker has the possibility to crash an enclave and further compromise the confidentiality or integrity of the SGX enclave. The attacker can also disclose the enclave cryptographic keys. According to the paper, there are two atomicity violation bugs. One is user-after-free bug, the other is TOCTTOU (Time Of Check Time Of Use) bug.

For the user-after-free bug, the following code shows an example of use-after-free bug occurring. From the code, we can see that the thread 1 is interrupted just after free pointer. However, thread 2 can still check the NULL and succeed even though the pointer has been freed. Thread 2 may thus be interrupted during its execution before the freed pointer can be used. However, the attack window for this is really small, and it need more time to wait for the occurring of interruption.

Thread 1:

...

free(pointer);

// Thread is not activated between these two statements

// Thread 1 is interrupted, exits the enclave

pointer = NULL;

...

Thread2:

...

if (pointer != NULL) {

    // Thread 2 uses a pointer to freed memory

}

...

To force segmentation fault by interrupt threads, the author used mprotect to remove the “read” and “execute” permissions from enclave pages. Figure 10 shows how it happens. This method can establish twice SIGSEGV. The reason is that memory access checks with SGX twice. The first time is that thread 1 calls free and an access violation occurs. It will cause a segmentation fault and an AEX. The permissions inside the page table are restored. Then, a timer is started and remove the permission upon expiration, which cause another SIGSEGV. Thread 1 is stopped and thread 2 is started and enter the enclave.

The example enclave containing a user-after-free bug is as following:

Figure.9

Figure.10: Interrupt enclave process

To analysis the TOCTTOU bug, we can consider the following example code. In this example code, three Ecalls enter the enclave and it include two threads. In ecall_checker_thread(), the thread check whether data contains ”bad data” and deny the access of “bad data”. If we delay the writer thread, the enclave execution will interrupt. Then, we let the writer thread proceed at lines 8 to 14 and change the value of data. After that, the checker thread can be resumed, and the access preformed at line 19. This will cause an Out of Bounds (OOB) access. To make sure the process will happen in the enclave, a timer is set before entering the enclave to configure the delay of thread execution. When different delays can be observed, the TOCTTOU bug is detected to be triggered.

Figure.11

This attack need lot of tries to figure out the proper delay time. It also requires a clear understanding of the mechanism of code running. It is impossible to figure it out if you don’t know how the synchronization bugs exists in the enclave. There is a simple way to protect against such kind of attack, which is disabling the exist of multithreading in the enclave.

Concerns and Conclusion

According to the attack method, they all come from side channel attack and have some basic idea about how the program in the enclave works. Therefore, for most of the condition, SGX is safe enough to protect the important secret file/data/program inside the enclave. The only concern is that people must trust Intel. Also, we need to make sure that there is no malware to execute malicious code inside the enclave. Although Intel SGX is a new technology, it protects the user from attack of other programs on the platform. This kind of protection is largely effective if we don’t consider some special side-channel attack.

Reference:

[1] https://blog.quarkslab.com/overview-of-intel-sgx-part-1-sgx-internals.html
[2] https://medium.com/magicofc/the-magic-of-intels-sgx-how-to-hello-it-sec-world-fb0295d6c33b

[3] Cache Attacks on Intel SGX: http://www.sharcs-project.eu/m/documents/papers/a02-gotzfried.pdf

[4] AsyncShock: Exploiting Synchronisation Bugs in Intel SGX Enclaves: 
https://www.ibr.cs.tu-bs.de/users/weichbr/papers/esorics2016.pdf
[5] https://blog.quarkslab.com/overview-of-intel-sgx-part-2-sgx-externals.html