As you know, the code executed in the enclave is seriously limited in its functionality. It cannot make system calls. It cannot perform I/O operations. It does not know the base address of the host application's code segment. It cannot jmp or call host application code. It has no idea about the address space structure that governs the host application (for example, which pages are mapped or what kind of data is located on those pages). It cannot ask the operating system to map a piece of the host application's memory to it (for example, through /proc/pid/maps). Naive attempts to blindly read an arbitrary memory region of a host application, not to mention attempts to write, will sooner or later (most likely the former) lead to the forced termination of the enclave program. This happens whenever the virtual address space region requested by the enclave is inaccessible to the host application.
Given such harsh realities, will a virus writer be able to use SGX enclaves to achieve his malicious goals?
Based on all of the above, it is generally accepted that an enclave is only capable of serving the host application, and that the enclave cannot exercise its own initiative, including malicious ones. This means that enclaves are of no practical value to virus writers. This hasty assumption is one of the reasons why SGX protection is asymmetrical: host application code cannot access enclave memory, while enclave code can read and write to any host application memory address.
Therefore, if malicious enclave code was able to make arbitrary system calls on behalf of the host application, execute arbitrary code on its behalf, scan the host application's memory and find abuseable ROP chains in it, it could seize complete control of 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. Without fear of even the most modern protective mechanisms, such as stack canaries and address sanitization.
We'll show you a few hacks that attackers use to overcome the limitations described above to take advantage of SGX for their own malicious purposes: ROP attacks. Either to execute arbitrary code disguised as a host application process (similar to process hollowing, which is often used by malware), or to disguise a ready-made malware (to save its malware from persecution by antiviruses and other defense mechanisms).
Hack for probing addresses to see if they can be read
Since the enclave does not know which ranges of the virtual address space are accessible to the host application, and since the enclave is forced to terminate when attempting to read an inaccessible address, the attacker is faced with the task of finding a way to fault-tolerantly scan the address space. Find a way to map available virtual addresses. The villain solves this problem by misusing Intel's TSX technology. Uses one of TSX's side effects: if the memory access function is placed in a TSX transaction, then exceptions arising from accessing invalid addresses are suppressed by TSX without reaching the operating system. If an attempt is made to access an invalid memory address, only the current transaction is aborted, not the entire enclave program. That. TSX allows an enclave to securely access any address from within a transaction - without the risk of collapse.
If the specified address is available host application, the TSX transaction is most often successful. In rare cases, it may fail due to external influences such as interrupts (such as scheduler interrupts), cache evictions, or simultaneous modification of a memory location by multiple processes. In these rare cases, the TSX returns an error code indicating that the failure is temporary. In these cases, you just need to restart the transaction.
If the specified address is unavailable host application, TSX suppresses the exception that occurred (the OS is not notified) and aborts the transaction. An error code is returned to the enclave code so that it can react to the fact that the transaction has been canceled. These error codes indicate that the address in question is not available to the host application.
This manipulation of TSX from inside the enclave has a nice feature for the villain: since most hardware performance counters are not updated at the time the enclave code is executed, it is impossible to track TSX transactions executed inside the enclave. Thus, malicious manipulation of the TSX remains completely invisible to the operating system.
Additionally, since the above hack does not rely on any system calls, it can neither be detected nor 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 the host application code for gadgets suitable for forming a ROP chain. At the same time, he does not need to probe every 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 an Intel i7-6700K). As a result, the villain receives a list of executable pages that are suitable for constructing a ROP chain.
Hack for probing addresses for writability
To carry out an enclave version of a ROP attack, an attacker needs to be able to search for writable unused memory areas of the host application. The attacker uses these memory locations 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 can misuse memory already allocated by the host application. If, of course, he manages to find such areas without collapsing the enclave.
The villain carries out this search by exploiting another side effect of TSX. First, as in the previous case, it probes the address for its existence, and then checks whether the page corresponding to this address is writable. To do this, the villain uses the following hack: he places a write function in a TSX transaction, and after it has completed, but before it has completed, he forcibly aborts the transaction (explicit abort).
By looking at the return code from a TSX transaction, the attacker understands whether it is writable. If it is an "explicit abortion", the villain understands that the recording would have been successful if he had followed through with it. If the page is read-only, then the transaction ends with an error other than “explicit abort”.
This manipulation of TSX has another feature that is nice for the villain (besides the impossibility of tracking through hardware performance counters): since all memory write commands are committed only if the transaction is successful, forcing the transaction to complete ensures that the probed memory cell remains unchanged.
Hack to redirect control flow
When performing a ROP attack from an enclave - unlike traditional ROP attacks - the attacker can gain control of the RIP register without exploiting any bugs in the attacked program (buffer overflow or something like that). An attacker 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 own ROP chain.
However, if the ROP chain is long, then overwriting a large chunk of the host application's stack can lead to data corruption and unexpected program behavior. The villain, who seeks to carry out his attack covertly, is not satisfied with this state of affairs. Therefore, it creates a fake temporary stack frame for itself and stores its ROP chain in it. The fake stack frame is placed in a random writable memory location, leaving the real stack intact.
What do the three hacks listed above give the villain?
(1) First, the malicious enclave through hack for probing addresses to see if they can be read, – searches the host application for abuseable ROP gadgets.
(2) Then by hack for probing addresses for writability, – a malicious enclave identifies areas in the host application’s memory that are suitable for injecting a payload.
(3) Next, the enclave creates a ROP chain from the gadgets discovered in step (1) and injects this chain into the host application stack.
(4) Finally, when the host application encounters the ROP chain created in the previous step, the malicious payload begins executing - with the privileges of the host application and the ability to make system calls.
How a villain uses these hacks to create ranzowari
After the host application transfers control to the enclave through one of the ECALLs (without suspecting that this enclave is malicious), the malicious enclave searches for free space in the memory of the host application for injecting code (taking as free spaces those sequences of cells that filled with zeros). Then through hack for probing addresses to see if they can be read, – the enclave searches for executable pages in the host application and generates a ROP chain that creates a new file named “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 is simply adding two numbers. What does this look like in code?
For ease of perception, let’s introduce some mnemonics through the definitions:
We save the original values of the RSP and RBP registers in order to restore normal operation of the host application after executing the payload:
We are looking for a suitable stack frame (see the code from the section “hack for redirecting control flow”).
Finding suitable ROP gadgets:
Finding a place to inject the payload:
We build a ROP chain:
This is how Intel's SGX technology, designed to counter malicious programs, is exploited by villains to achieve opposite goals.
Source: habr.com