A group of researchers from the Vrije Universiteit Amsterdam and IBM has developed a new attack on the speculative execution mechanism in modern processors, codenamed GhostRace (CVE-2024-2193). The problem appears in processors manufactured by Intel, AMD, ARM and IBM. To demonstrate the principles of the attack, an exploit prototype has been published that allows extracting data from Linux kernel memory with a performance of 12 KB per second with a reliability level typical of Specter-class attacks. When carrying out attacks on virtualization systems, an attacker from a guest system can determine the memory contents of the host environment or other guest systems.
The proposed attack method manipulates the occurrence of speculative race conditions that can lead to access to already freed memory areas if the processor incorrectly predicts branches in code that performs conditional operations with thread synchronization primitives, such as mutex and spinlock. Speculative memory accesses that occur after a misprediction is detected are discarded by the processor, but traces of their execution remain in the processor cache and can then be retrieved using side-channel analysis.
By analogy with the exploitation of Specter v1 vulnerabilities, the GhostRace attack requires the presence of certain sequences of instructions (gadgets) in the kernel, leading to speculative code execution depending on external conditions that can be influenced by the attacker. For optimization purposes, the processor begins to execute 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 sections of code in which the state is checked in an endless loop and the loop is exited after the access lock to the resource is removed. Accordingly, when executing instructions speculatively, it is possible to achieve a false triggering of a transition and execution of a set of instructions protected by a lock, despite the fact that the resource lock remains unreleased.
When analyzing the code of the Linux 5.15.83 kernel, researchers identified 1283 gadgets that lead to speculative access to already freed 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 execution of branching operations (x86, ARM, RISC-V, etc.) .
To block the attack, it is proposed to use serialization of synchronization primitives, i.e. adding a LFENCE processor instruction after the cmpxchq instruction, which checks the locking state. The proposed protection method for inclusion in the Linux kernel results in a performance penalty of approximately 5% on the LMBench benchmark because the LFENCE call disables preemptive execution of subsequent instructions before all previous operations have been committed.
Linux kernel developers and CPU manufacturing companies were notified of the problem in late 2023. AMD published a report on the presence of the vulnerability, in which it recommended using standard techniques to protect against Specter v1 attacks. Intel and ARM have not yet responded. The Linux kernel developers do not intend to use the proposed method of serializing synchronization primitives in the near future due to the performance penalty, but have already implemented the necessary restrictions to protect against the related IPI Storming (Inter-Process Interrupt Storming) exploitation technique (CVE-2024-26602) that is used in an exploit to interrupt a process at the right moment (flooding the CPU core with interrupts that prevent the completion of 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 the leaking gadgets have not yet been identified in the Xen hypervisor, the Xen developers have prepared changes to implement the protected LOCK_HARDEN locking mechanism, similar to the previously added BRANCH_HARDEN protection method. Due to the possible negative impact on performance, as well as the lack of evidence of the possibility of an attack on Xen, the LOCK_HARDEN mode is disabled by default.
Source: opennet.ru
