SGX Malvar: how villains exploit Intel's new technology for the purposes for which it was conceived

As you know, the code executed in the enclave is seriously limited in its functionality. He cannot make system calls. It cannot perform I / O operations. He does not know the base address of the host application code segment. It cannot jmp and call host code. He has no idea about the structure of the address space that guides the host application (for example, which pages are promoted or what kind of data is placed on these pages). He cannot ask the operating system to append a piece of memory to the host application (for example, via / proc / pid / maps). Naive attempts to read a blind arbitrary memory area of ​​the host application — not to mention write attempts — sooner or later (rather the first) will lead to the forced completion of the enclave program. This happens whenever the virtual address space area requested by the enclave is inaccessible to the host application.

With such harsh realities, will a virus writer be able to use SGX enclaves to realize his malicious goals?

- Hack for probing addresses for the possibility of reading them
- Hack to probe addresses for writeability
- Hack to redirect control flow
- What give the villain the three hacks listed above
- How the villain uses these hacks to create ranzomvari

Based on all of the above, it is generally accepted that the enclave is only capable of serving the host application, and that the enclave cannot take its own initiative, including malicious. So, for virus writers, enclaves are not of practical value. This hasty assumption is one of the reasons why SGX protection is asymmetric: the host application code cannot access the enclave memory, while the enclave code can read and write to any memory address of the host application.

Therefore, if a malicious enclave code succeeds in making arbitrary system calls on behalf of the host application, executing arbitrary code on its behalf, scanning the memory of the host application and finding the ROP chain suitable for abuse in it, it will be able to take complete control over host application in stealth mode. It can not only steal and encrypt user files, but also act on behalf of the user. For example, send phishing emails on his behalf or conduct DoS attacks. At the same time, you are not afraid of even the most modern protective mechanisms, such as stack canaries and sanitization of addresses.

We will show some hacks through which the villains overcome the above limitations, trying to take advantage of the benefits of SGX for their malicious purposes: in carrying out ROP attacks. Either to execute arbitrary code disguised as a host sawing process (similar to the process hollowing, which is often used by malware), or to mask an already prepared malware (to save its malware from persecution by antiviruses and other protective mechanisms).

Hack for probing addresses for the possibility of reading them

Since the enclave does not know what ranges of the virtual address space are available to the host application, and because when you try to read an inaccessible address, the enclave is forcibly terminated, the villain is faced with the task of finding a way to fail-safe scanning of the address space. Find a way to map available virtual addresses. The villain solves this problem by misusing Intel's TSX technology. It uses one of the side effects of TSX: if the memory access function is placed in a TSX transaction, then exceptions arising from accessing invalid addresses are suppressed by TSX before reaching the operating system. When you try to access an invalid memory address, only the current transaction is interrupted, and not the entire enclave program. T.O. TSX allows the enclave to safely access any address from within the transaction - without the risk of collapse.

If the specified address is available to the host application, the TSX transaction most often succeeds. In rare cases, it may fail due to external influences, such as interrupts (for example, scheduler interruptions), crowding out of the cache, or simultaneous memory cell changes by several processes. In these rare cases, TSX returns an error code indicating that the failure occurred is temporary. In these cases, you just need to restart the transaction.

If the specified address is not available to the host application, TSX suppresses the exception (the OS is not notified) and cancels the transaction. An error code is returned to the enclave code so that it can respond to the fact that the transaction was canceled. These error codes indicate that the address in question is not available to the host application.

Such manipulation of TSX from the inside of the enclave has a pleasant feature for the villain: since at the time of execution of the enclave code most hardware performance counters are not updated, it is impossible to track TSX transactions performed inside the enclave using them. Thus, malicious fraud with TSX'om remain completely invisible to the operating system.

In addition, since the hack described above does not rely on any system calls, it cannot be detected or prevented by simply blocking system calls; which usually gives a positive result in the fight against "egg hunting."

The villain uses the hack described above to search for gadgets in the host application code that are suitable for forming an ROP chain. However, he does not need to probe each address. It is enough to probe one address from each page of the virtual address space. Probing all 16 gigabytes of memory takes about 45 minutes (on Intel i7-6700K). As a result, the villain gets a list of executable pages that are suitable for constructing an ROP chain.

Hack for probing addresses for writeability

To implement an enclave version of a ROP attack, the villain needs the ability to search for writable unused portions of the host application’s memory. The villain uses these sections of memory to inject a fake stack frame and to inject a payload (shellcode). The bottom line is that a malicious enclave is not able to require the host application to allocate memory for itself, but instead it can use for other purposes the memory allocated by the host application. Unless of course he manages to find such sites without collapsing the enclave.

The villain carries out this search, exploiting another side effect of TSX. First, he, as in the previous case, probes the address for its existence, and then checks whether the page corresponding to this address is accessible for writing. To do this, the villain uses the following hack: puts the write function in the TSX transaction, and after it is completed, but before it is completed, it forcibly breaks the transaction (explicit abort).

Looking at the return code from a TSX transaction, the villain realizes whether it is writable. If it is “explicit abort”, the villain realizes that the record would be successful if he brought it to the end. If the page is read-only, then the transaction fails with an error other than “explicit abort”.

Such manipulation by TSX has another feature that is pleasant for the villain (in addition to being unable to track through hardware performance counters): since all write commands to the memory are only recorded if the transaction was successful, forcing the transaction to complete ensures that the probed memory cell remains unchanged.

Control flow redirect hack

When carrying out a ROP attack from an enclave — unlike traditional ROP attacks — the villain can gain control of the RIP register without exploiting any bugs in the attacked program (buffer overflow or something like that). The villain can directly overwrite the value of the RIP register stored on the stack. In particular, it can replace the value of this register with its ROP chain.

However, if the ROP chain is long, then overwriting a large piece of the stack of the host application can lead to data corruption and unexpected program behavior. A villain who seeks to conduct his attack stealthily, this state of affairs does not suit. Therefore, he creates a fake temporary stack frame for himself and stores his ROP chain in it. A fake stack frame is placed in an arbitrary memory location that is writable - so that the true stack remains untouched.

What give the villain the three hacks listed above

(1) First, a malicious enclave, through a hack to probe addresses for the possibility of reading them , searches the host application for ROP gadgets that can be abused.

(2) Then, using a hack to probe the addresses for writeability , the malicious enclave identifies in the host application memory areas suitable for injecting the payload.

(3) Next, the enclave creates an ROP chain from the gadgets found in step (1) and injects that chain into the host application stack.

(4) Finally, when the host application stumbles upon the ROP chain created in the previous step, malicious payload execution begins, with the privileges of the host application and with the ability to make system calls.

How the villain uses these hacks to create ranzomvari

After the host application transfers control to the enclave through any of the ECALLs (without suspecting that this enclave is malicious), the malicious enclave looks for free space in the host application's memory for code injection (for those places it takes those sequences of cells that filled with zeros). Then, using a hack to probe the addresses for readability , the enclave searches the executable pages in the host application and generates a ROP chain that creates a new file called “RANSOM” in the current directory (in a real attack, the enclave encrypts existing user files) and displays a ransom message. At the same time, the host application naively believes that the enclave simply adds up two numbers. What does it look like in code?

For ease of perception, we introduce some mnemonics through defines:

We preserve the initial values ​​of the RSP and RBP registers in order to restore the normal operation of the host application after performing the payload:

We are looking for a suitable stack frame (see the code in the “hack for redirecting control flow” section).

Find suitable ROP gadgets:

Find a place to inject the payload:

Building a ROP chain:

In this way, Intel’s SGX technology, designed to withstand malicious programs, is exploited by villains to accomplish opposing goals.


All Articles