قالب وردپرس درنا توس
Home / Technology / Researchers use Intel SGX to keep malware out of the reach of antivirus software

Researchers use Intel SGX to keep malware out of the reach of antivirus software



  Intel Skylake dies.

Intel Skylake dies.

Researchers have found a way to run malicious code on systems with Intel processors so that malware can not be analyzed or identified by antivirus software Use the processor's own features to protect the malformed code. Apart from the fact that malware is generally more difficult to investigate, bad actors could use this protection to write, for example, ransomware applications that never reveal their encryption keys in readable memory, making recovery from attacks more difficult.

The research, performed by Michael Schwarz, Samuel Weiser and Daniel Gruss (one of the researchers behind last year's Specter attack) at Graz University of Technology, uses a feature that Intel has developed with its Skylake SGX ("Software Guard eXtensions "). SGX allows programs to extract enclaves in which both the code and the data the code is working with are protected, their confidentiality (nothing else in the system can be spied on) and integrity (any manipulation of the system) Codes or the code) data can be recognized). The contents of an enclave are transparently encrypted each time they are written to RAM and decrypted as they are read. The processor controls access to the enclave memory: any attempt to access the enclave memory from outside the enclave is blocked. The decryption and encryption is done only for the code in the enclave.

SGX was used as a solution to a number of security concerns when a developer wants to protect code, data, or both from prying eyes. For example, an SGX enclave running on a cloud platform can be used to execute custom proprietary algorithms so that even the cloud provider can not determine what the algorithms are doing. On a client computer, the SGX enclave could similarly be used to enforce Digital Rights Management (DRM) restrictions. The decryption process and decryption keys that the DRM used could be kept in the enclave, making them unreadable to the rest of the system. There are biometric products on the market that use SGX enclaves to process the biometric data and securely store it so that it can not be manipulated.

SGX was developed for this particular threat model: the enclave is trustworthy and somewhat sensitive, but anything else (the application, the operating system, and even the hypervisor) is potentially hostile. While there have been attacks on this threat model (for example, misspelled SGX enclaves may be vulnerable to timing attacks or meltdown-style attacks), it does seem robust as long as certain best practices are followed.

We Should Ignore Intel's Approaches Threat Model

The researchers use this robustness for nefarious purposes and consider the question: what happens if the code in the enclave is harmful? SGX makes it impossible for the malware software to examine or analyze the running malware. This would make it a promising place to place malicious code. However, the code in an enclave is pretty limited. In particular, no operating system calls are provided. It can not open files, read data from the hard disk or write to the hard disk. All these things have to be done from outside the enclave. Naïvely, it seems that a hypothetical SGX-based ransomware application outside the SGX enclave needs significant code : The parts that would list all your documents, read them and overwrite them with their encrypted versions would not be protected , Only the encryption operation itself would take place within the enclave.

However, the enclave code can read and write anywhere in the unencrypted process memory. While nothing can look inward from outside the enclave, everything inside the enclave can see outward. The researchers used this ability to search the process memory and find the information needed to create a ROP payload (ROP) to execute the code of their choice. This concatenates small fragments of executable code that are part of the host application to do things that the host application did not intend.

Reading and writing required a trick. When the enclave code attempts to read unallocated memory or write to unallocated or read-only memory, an exception is typically generated and the processor shifts out of the enclave to handle the exception. This would make it impossible to browse the host's memory because the malicious enclave would stop running after the exception occurred and the program would most likely crash. To cope with this, the researchers have reworked a technique that has also proven useful for the meltdown attack: they used a different Intel processor function, the Transactional Synchronization Extensions (TSX).

The TSX provides a limited form of transactional memory. Transactional memory allows a thread to change a number of different locations and then publish those changes in a single atomic update, allowing other threads to make either none of the modifications or all of the changes without the partially written intermediate stages If a second thread tried to change the same memory while the first thread was performing all its modifications, the attempt to publish the modifications will be aborted.

The intent of TSX is to simplify the development of multithreaded data structures. t Use locks to protect their changes. If done correctly, they can be much faster than lock-based structures, especially under heavy load. However, TSX has a particularly benign side effect: attempts to read or write unallocated or non-writable memory within a transaction do not generate exceptions. Instead, they simply cancel the transaction. Critically, this transaction does not leave the enclave; Instead, it is handled in the enclave.

This gives the malevolent enclave everything it needs for its dirty work. It searches the memory of the host process to find the components for its ROP payload and anywhere to write that payload, and then redirects the processor to execute that payload. For example, the payload would typically flag a portion of the memory as executable so that the malware can provide its own set of supporting functions. For example, ransomware must list, open, read, and then overwrite files that it can access. Critical encryption occurs within the enclave, making it impossible to extract the encryption key or even parse the malware to find out which algorithm is encrypting the data.

Signed, sealed and delivered

The processor will not do this Load old code into an enclave. Enclave developers need a "commercial agreement" with Intel to develop enclaves. Under this agreement, Intel blends a code-signing certificate owned by the developer and adds it to a whitelist. A special Intel-designed enclave (implicitly trusted by the processor) then examines each loaded code to make sure that it has been signed by one of the whitelist certificates. A malware developer may not wish to enter into such an agreement with Intel, and the terms of the agreement specifically prohibit the development of SGX malware, although the value of this restriction may be called into question.

However, this could be affected by the case of writing an enclave that has loaded a payload from the hard drive and then executed it; The loader would need a whitelist signature, but the payload would not. This approach is useful anyway because enclave code is executed in encrypted storage, but the enclave libraries stored on disk are not self-encrypted. With dynamic loading, the payload on disk could be encrypted and decrypted only when it is loaded into the enclave. The loader itself would not be malicious and would somehow be credible that something disgraceful was intended. In fact, an enclave could be quite benevolent but contain exploitable flaws that allow attackers to inject their malicious code into it. SGX does not protect against old coding errors.

This particular aspect of SGX has been widely criticized for making Intel a gatekeeper for all SGX applications. Accordingly, second-generation SGX systems (including some eighth-generation and new-generation processors) relax this restriction, allowing enclaves that are not signed by Intel's whitelist signers to be launched in a way that is not possible : Malware may be located in a protected enclave so that the unencrypted code of that malware is never exposed to the host operating system, including antivirus software. In addition, the enclave does not restrict the malware: it can undermine the host application for accessing operating system APIs, allowing attacks such as ransomware encryption of victim's files.

The attack is esoteric, but as SGX becomes more common, researchers will find more and more ways to undermine and co-opt it. We have seen similar things with the introduction of hardware virtualization support. this opened the door to a new kind of rootkit that could hide itself from the operating system by using a valuable function for bad things.

Intel was informed about the investigation and replied:

Intel is aware of this investigation is based on assumptions that are outside of the threat model for Intel® SGX. The value of Intel SGX is running code in a protected enclave. However, Intel SGX does not guarantee that the code executed in the enclave comes from a trusted source. In all cases, we recommend using programs, files, apps, and plugins from trusted sources. Protecting customers is still a key priority for us, and we want to thank Michael Schwarz, Samuel Weiser and Daniel Gruss for their ongoing research and collaboration with Intel on coordinated vulnerability disclosure. Intel is worried SGX is working that way as it should, and protects the contents of the enclave from the rest of the system. If you do something unpleasant in the enclave, the company makes no promises that your computer will not be bad. SGX is simply not meant to protect against it.

That may be so, but SGX offers developers some powerful abilities they did not have before. "How are bad guys doing it?" This is an obvious question, because if it gives them an advantage, do it yourself.


Source link