The fundamental design of the mutex_lock synchronization mechanism in the Linux x86-64 kernel architecture can lead to vulnerabilities associated with speculative execution attacks.
Race conditions occur when multiple threads access a shared resource without proper synchronization, often resulting in vulnerabilities like concurrent use-after-free. Operating systems mitigate these issues using synchronization primitives such as mutexes and spinlocks.
Speculative execution enhances system performance by preemptively executing tasks when resources are available. However, attackers can exploit traces of these executions in the CPU’s cache, buffer, and branch predictors. They may even manipulate speculative execution paths through malicious software to access privileged data from a different execution context. Spectre v1 attacks exploit speculative execution of conditional branch instructions, as detailed in the “Spectre Side Channels” article on kernel.org.
Previous research focused on speculative execution attacks but overlooked those involving race conditions. Race conditions occur when multiple threads access the same resource without proper synchronisation, potentially enabling attackers to deceive systems into executing unauthorised actions alongside normal processes. This recent study delves into a speculative race condition attack against modern CPU speculative execution facilities.
In this study, the authors introduced GhostRace, the first security analysis of these primitives on speculatively executed code paths. The main discovery of this research is that all common synchronization primitives can be bypassed on speculative paths, converting architecturally race-free critical regions into Speculative Race Conditions (SRCs). Additionally, SCUAF information disclosure attacks against the kernel are not only feasible but can achieve reliability comparable to traditional Spectre attacks. The author devised a novel technique to create an unbounded race window, accommodating any number of SCUAF invocations necessary for an end-to-end attack within a single race window. To mitigate this new attack surface, they proposed a generic SRC mitigation to fortify all affected synchronization primitives on Linux.
#IBM and #VUSec lab published research on this security issue and potential solutions
Reference:
