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

Researchers use Intel SGX to put malware beyond the reach of antivirus software



  Intel Skylake fired.

Intel Skylake fired.

Researchers have found a way to execute malicious code on systems with Intel processors so that malware can not be analyzed or identified by antivirus software, using processor features to protect the wrong code. In addition to making malware generally harder to examine, bad actors could use this protection to, for example, write ransomware applications that never reveal their readable memory encryption keys, making recovery from attack more difficult.

performed at the Graz University of Technology by Michael Schwarz, Samuel Weiser and Daniel Gruss (one of the researchers behind the Specter attack last year), uses a feature introduced by Intel with its Skylake processors called SGX ("Software Guard eXtensions"). SGX allows programs to excavate enclaves in which both the code and the data with which the code works are protected to ensure their confidentiality (nothing else on the system can spy on them) and integrity (any code tampering or data can be detected). The contents of an & # 39; enclave are encrypted transparently whenever they are written to RAM and decoded after being read. The processor governs access to the memory of the enclave: any attempt to access the memory of the enclave from the external code to the enclave is blocked; decoding and encryption occur only for the code inside the enclave.

SGX has been promoted as a solution to a range of security issues when a developer wants to protect code, data or both from prying eyes. For example, you can use an SGX enclave running on a cloud platform to run custom proprietary algorithms, so that the cloud provider can not determine what the algorithms are doing. On a client computer, the SGX enclave could be used similarly to impose DRM (digital rights management) restrictions; the decryption process and the decryption keys that the DRM used could contain inside the enclave, making it unreadable to the rest of the system. On the market there are biometric products that use SGX enclaves to process biometric data and store them securely so that they can not be tampered with.

SGX was designed for this particular threat model: the enclave is reliable and contains something sensitive, but everything else (the application, the operating system and even the hypervisor) is potentially hostile. Although there have been attacks on this threat model (for example, improperly written SGX enclaves may be vulnerable to time attacks or Meltdown attacks), it seems robust as long as some best practices are followed.

Ignore Intel Threat Model

Researchers are using that robustness for nefarious purposes and considering the question: what happens if it is the code in the enclave that is mischievous? SGX by design will make it impossible for the antimalware software to inspect or analyze the running malware. This would make a promising place to insert malicious code. However, the code in an & # 39; enclave is rather limited. In particular, it does not envisage making calls to the operating system; can not open files, read data from disk or write to disk. All these things must be performed outside the enclave. As such, it would naively be assumed that a hypothetical SGX-based ransomware application needs a considerable code outside of the SGX enclave: the pieces to enumerate all your documents, read them and overwriting them with their encrypted versions not being protected Only the encryption operation would have occurred within the enclave.

The encoding code, however, has the ability to read and write anywhere in the unencrypted process memory; while nothing from the outside of the enclave can look inside, anything inside the enclave is free to look out. The researchers used this ability to examine the process memory and find the information needed to construct a performance-oriented programming payload (ROP) to execute the code of their choice. This groups small fragments of executable code that are part of the host application to do things that the host application did not intend to do.

Some tricks were necessary to perform this reading and writing. If the enclave code tries to read unallocated memory or to write to unallocated or read-only memory, the normal behavior is that an exception is thrown and that the processor passes from the enclave to handle the 39; exception. This would make it impossible to scan the host memory, because once the exception occurred, the malicious enclave would no longer be running and, in all likelihood, the program would stop. To cope with this, the researchers revisited a technique that proved useful in the Meltdown attack: they used another feature of the Intel processor, Transactional Synchronization eXtensions (TSX).

TSX provides a constrained form of transactional memory. Transactional memory allows a thread to modify a group of different memory locations and then publish those changes into a single atomic update, so that other threads see none of the changes or all of the changes, without being able to see any of the partially written intermediate stages. If a second thread tried to change the same memory while the first thread was making all of its changes, then the attempt to publish the changes was interrupted.

The intent of TSX is to make it easier to develop multithreaded data structures that don & # 39; use locks to protect their modifications; done correctly, these can be much faster than lock-based structures, especially under heavy load. But TSX has a particularly convenient side effect: attempts to read or write unallocated or non-writable memory within a transaction do not generate exceptions. Instead, they interrupt the transaction. Critically, this interruption of the transaction does not leave the enclave; instead, it is managed within the enclave.

This provides the evil enclave with everything it needs to do its dirty work. It analyzes the memory of the host process to find the components for its payload ROP and somewhere to write that payload, and then redirects the processor to execute that payload. In general, the payload would do something like marking a section of memory as executable, so malware can put its own set of support functions, for example the ransomware has to list the files, open them, read them and then overwrite them, somewhere that they can log into. Critical cryptography occurs within the enclave, making it impossible to extract the cryptographic key or even analyze the malware to find out what algorithm it is using to encrypt the data.

Signed, sealed, and delivered

The processor does not load any old code into an enclave. Enclave developers need a "trade agreement" with Intel to develop enclaves. Under this agreement, Intel blesses a code signing certificate from the developer and adds it to a whitelist. A special enclave developed by Intel (which is implicitly trusted by the processor) then inspects each piece of code while it is being loaded to make sure it has been signed by one of the authorized certificates. A malware developer may not want to enter into such an agreement with Intel, and the terms of the agreement expressly prohibit the development of SGX malware, although the value of this restriction may be challenged.

This could be subverted, however, by writing an & quot; enclave & quot; loading a payload from the disk and then executing it; the charger would need a white signature, but the payload no. This approach is still useful, since while the enclave code is executed in encrypted memory, the enclave libraries stored on the disk are not themselves encrypted. With dynamic loading, the payload to disk could be encrypted and decrypted only once loaded into the enclave. The charger itself would not be mischievous, giving a certain amount of plausible denial that anything nefarious was intended. In fact, an enclave could be entirely benign but contain exploitable flaws that allow attackers to inject their malicious code into the interior; SGX does not protect against simple coding errors.

This particular aspect of SGX has been widely criticized, as it makes Intel a gatekeeper of sorts for all SGX applications. As a result, second generation SGX systems (which includes some eighth or newer brand processors) mitigate this limitation, making it possible to start enclaves that are not signed by authorized Intel signatories.

As such, research shows that SGX can be used in a way that in reality should not be possible: malware can reside inside a protected "enclave" so that the unencrypted code of that malware is never exposed to the host operating system, including antivirus software. In addition, malware is not bound by the enclave: it can subvert the host application to access the operating system's API, opening the door to attacks such as ransomware-style encryption of a victim's files.

Information about the threat model …

The attack is esoteric, but when SGX becomes more common, the researchers will punish it more and more and will find ways to subvert and co-opt. We've seen similar things with the introduction of hardware virtualization support; which opened the door to a new generation of rootkits that could hide from the operating system, taking a valuable feature and using it for negative things.

Intel was informed of the research, responding:

Intel is aware of this research that is based on assumptions that are outside the threat model for Intel® SGX. The value of Intel SGX is to run 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 that you use programs, files, apps, and plug-ins from trusted sources. Protecting customers continues to be a key priority for us, and we would like to thank Michael Schwarz, Samuel Weiser and Daniel Gruss for their ongoing research and for working with Intel on the dissemination of coordinated vulnerabilities.

In other words, as far as Intel is worried, SGX is working as it should, protecting the contents of the enclave from the rest of the system. If you manage something bad in the enclave, the company does not promise that bad things will not happen to your computer; SGX is simply not designed to protect it.

It could be like that, but SGX offers developers some powerful features they did not have before. "How will the villains make a mess with this?" it's an obvious question to ask, because if it gives them an edge, mess it up.


Source link