A newly disclosed vulnerability affecting Intel processors could be abused by an adversary to gain access to sensitive information stored within enclaves and even run arbitrary code on vulnerable systems. The vulnerability was discovered by a group of academics from ETH Zurich, the National University of Singapore, and the Chinese National University of Defence Technology in early May 2021, who used it to stage a confidential data disclosure attack called "SmashEx" that can corrupt private data housed in the enclave and break its integrity.
SGX (short for Software Guard eXtensions) was introduced with Intel's Skylake processors, and it allows developers to run selected application modules in a completely isolated secure compartment of memory known as an enclave or a Trusted Execution Environment (TEE), which is designed to be protected from processes with higher privilege levels such as the operating system. Even if a computer's operating system has been tampered with or is under assault, SGX assures that data remains secure.
"The SGX design allows the OS to interrupt the enclave execution through customizable hardware exceptions at any moment during normal operation," the researchers explained. This feature enables in-enclave exception or signal handling in enclave runtimes (e.g., Intel SGX SDK and Microsoft Open Enclave), however it also exposes enclaves to re-entrancy problems. SmashEx is an attack that takes advantage of enclave SDKs that don't properly handle re-entrancy in their exceptional handling.
Outside Calls, or OCALLS, are a feature of an enclave that allows enclave functions to call out to an untrusted programme and then return to the enclave. When the enclave also handles in-enclave exceptions (such as timer interrupt or division-by-zero), however, the vulnerability allows a local attacker to hijack the control flow of execution by injecting an asynchronous exception shortly after the enclave is entered. The adversary can then use this capability to alter the in-enclave memory, leaking sensitive data such as RSA private keys or executing malicious code.
Because SmashEx affects runtimes that support in-enclave exception handling, the researchers advise that "such OCALL return flow and exception handling flow should be written with care to ensure that they interleave safely," and that "when the OCALL return flow is interrupted, the enclave should be in a consistent state for the exception handling flow to progress correctly, and when the exception handling flow completes, the enclave state should also be ready for the enclave state to progress correctly."
Similar attacks that broke SGX enclaves to obtain data have been seen in recent years. PlunderVolt, SgxSpectre, Foreshadow, BranchScope, Platypus, V0LTpwn, Game of Threads, AsyncShock, The Guard's Dilemma, and Iago are some of the previous instances. Furthermore, a 2019 analysis of eight prominent enclave software development kits, or software libraries used by app developers to allow their apps to interface with and store data inside enclaves, discovered 35 different vulnerabilities across all SDKs analysed, including SGX. The SmashEx assault, however, is significantly more harmful than the others outlined above, according to researchers, because it not only leaks data from inside SGX enclaves, but it can also corrupt it if necessary.
The lack of atomicity primitives in SGX enclaves gives rise to SmashEx. Unlike an OS kernel or a traditional application, which can ask a trusted entity (in this case, the hardware or the OS) to prevent the asynchronous occurrence or delivery of exceptions, software running inside an SGX enclave does not have easy access to such primitives because the OS is untrustworthy and the SGX hardware does not provide them. Without these primitives, an SGX enclave can be interrupted and re-entered at any moment, even if it is in an unrecoverable condition.
Both Intel SGX SDK and Open Enclave have included patches to defend against SmashEx in their latest release versions. Their patches are purely software-based and trade the enclave functionality for security. As hinted at above, we believe that providing atomicity support in hardware is a better defence in the long run. On a single CPU machine an instruction sequence can be made "atomic" in the sense that it cannot be interrupted in the middle if interrupts are shut off. This means that synchronization primitives can be written quite simply once the CPU enters kernel mode and can access the interrupt control registers.
The strength of your systems is determined by the weakest link. A hasty implementation, or one that does not follow a consistent approach, is likely to leave several technical configuration flaws that could be exploited in the future. Cybersecuritylinks can analyse and provide a succinct IT security audit of your systems' technical configuration, highlighting opportunities for improvement. This knowledge may then be incorporated into your secure build standards, ensuring the future security of your component builds.
Comentários