GhostRace - an attack on the speculative execution mechanism in Intel, AMD, ARM, and IBM processors

Teacher

Professional
Messages
2,674
Reputation
9
Reaction score
668
Points
113
A group of researchers from the Free University of Amsterdam and IBM has developed a new version of the attack on the speculative execution mechanism in modern processors, codenamed GhostRace (CVE-2024-2193). The problem manifests itself in processors manufactured by Intel, AMD, ARM, and IBM. To demonstrate the principles of the attack, a prototype exploit has been published that allows data to be extracted from the Linux kernel memory with a performance of 12 Kb per second at a level of reliability typical of Spectre attacks. When attacking virtualization systems, an attacker from the guest system can determine the memory contents of the host environment or other guest systems.

The proposed attack method manipulates the occurrence of race states in speculative mode, which can lead to access to already released memory areas, in case of incorrect branch prediction by the processor in code that performs conditional operations with thread synchronization primitives, such as mutex and spinlock. Speculative memory accesses that occur after determining an incorrect prediction are discarded by the processor, but traces of their execution are deposited in the processor cache and can then be extracted using analysis via third-party channels.

Similar to exploiting the Spectre v1 vulnerabilities, a GhostRace attack requires certain sequences of instructions (gadgets) in the kernel that lead to speculative code execution depending on external conditions that the attacker can influence. For optimization purposes, the processor starts executing such gadgets in speculative mode, but then determines that the branch prediction was not justified and rolls back the operations to their original state.

A gadget is formed, for example, from code sections where the state is checked in an infinite loop and the loop is exited after the resource access lock is released. Accordingly, speculative execution of instructions can result in a false jump and execution of a lock-protected set of instructions, even though the actual resource lock remains unchecked.

28dd61132c.png


When analyzing the code of the Linux kernel 5.15.83, researchers identified 1283 gadgets that lead to speculative access to already released memory (SCUAF - Speculative Concurrent Use-After-Free). Potentially, an attack can be made on virtualization systems, any OS kernels and programs in which thread synchronization primitives are checked using conditional statements, and the code is executed on platforms that allow speculative branching operations (x86, ARM, RISC-V, etc.).

To block the attack, it is suggested to use serialization of synchronization primitives, i.e. adding the LFENCE processor instruction after the cmpxchq command that checks the lock status. The protection method proposed for inclusion in the Linux kernel leads to a performance penalty of approximately 5% when passing the LMBench test, since the LFENCE call prohibits preemptive execution of the following instructions before all previous operations are committed.

Linux kernel developers and CPU manufacturers were notified of the problem in late 2023. AMD has published a vulnerability report, which recommended using standard techniques to protect against attacks of the Spectre v1 class. Intel and ARM have not yet responded.

Linux kernel developers do not intend to use the proposed method of serialization of synchronization primitives in the near future due to performance degradation, but they have already implemented the necessary restrictions to protect against the accompanying IPI Storming (Inter-Process Interrupt Storming) exploitation technique (CVE-2024-26602), which is used to interrupt the process at the right moment (flooding the CPU core interrupts that prevent an interrupt handler that was triggered while the process was running) in order to provide a time window for speculative access to already freed memory.

Despite the fact that no gadgets causing leaks have yet been identified in Xen, the hypervisor developers have prepared changes with the implementation of the secure lock mechanism LOCK_HARDEN, similar to the previously added BRANCH_HARDEN protection method. Due to possible negative performance impacts, LOCK_HARDEN mode is disabled by default.
 
Top