A consortium of researchers has unearthed a novel data leakage assault affecting contemporary CPU architectures that support speculative execution.
Termed PhantomFleet (CVE-2024-2193), it constitutes a variant of the transient execution CPU susceptibility commonly recognized as Spectre v1 (CVE-2017-5753). This method amalgamates speculative execution with race conditions.
“Conventional synchronization primitives, which are built utilizing conditional branches, can be circumvented on speculative pathways using a branch misprediction assault, thus transforming all architecturally race-free critical zones into Speculative Race Conditions (SRCs), thereby granting malevolent entities the ability to siphon data from the target,” as articulated by the researchers.
These revelations have emerged from the Systems Security Research Group at IBM Research Europe and VUSec, the latter being the entity that disclosed an additional side-channel attack titled SLAM, targeting contemporary processors in December 2023.
Cybersecurity Spectre denotes a category of side-channel assaults that exploit branch prediction and speculative execution on modern CPUs to access privileged data in memory, evading the isolation safeguards between applications.
While speculative execution serves as a performance enhancement technique employed by the majority of CPUs, Spectre assaults capitalize on the residual traces of memory accesses or computations left behind by erroneous predictions in the processor’s caches.
“Spectre attacks entice a target to speculatively execute operations that would not transpire during strictly serialized, in-order processing of the program’s directives, thereby leaking the target’s confidential data via a clandestine channel to the adversary,” elucidated the researchers behind the Spectre assault in January 2018.
The unveiling of these vulnerabilities, in conjunction with Meltdown, has instigated a broader reassessment of microprocessor architecture over the years, even prompting the MITRE Common Weakness Enumeration (CWE) program to incorporate four new vulnerabilities linked to hardware microarchitectures stemming from transient execution (ranging from CWE-1420 to CWE-1423) toward the end of the previous month.
What sets PhantomFleet apart is its capacity to empower an unauthenticated assailant to exfiltrate arbitrary data from the processor via race conditions, thereby accessing speculative executable code paths by leveraging a mechanism termed a Speculative Concurrent Use-After-Free (SCUAF) attack.
A race condition denotes an undesirable scenario arising when two or more processes endeavor to access the same shared resource without adequate synchronization, consequently yielding inconsistent outcomes and furnishing an opening for malicious activities by an assailant.
“In terms of characteristics and exploitation approach, an SRC vulnerability mirrors a traditional race condition,” expounded the CERT Coordination Center (CERT/CC) in an advisory.
“However, it deviates in the sense that the assailant exploits said race condition on a transiently executed pathway stemming from a mis-speculated branch (analogous to Spectre v1), targeting a racy code segment or gadget that ultimately reveals information to the assailant.”
The upshot is that it facilitates an assailant with access to CPU resources to retrieve arbitrary sensitive data from host memory.
Cybersecurity “Any software, such as an operating system, hypervisor, etc., that implements synchronization primitives through conditional branches devoid of any serializing instruction on that pathway and operates on any microarchitecture (e.g., x86, ARM, RISC-V, etc.), which permits conditional branches to be speculatively executed, is susceptible to SRCs,” stated VUSec.
Following responsible disclosure, AMD affirmed that its existing recommendations for Spectre “remain relevant to mitigate this vulnerability.” The custodians of the Xen open-source hypervisor acknowledged that all versions are affected, although they indicated that it is improbable to pose a significant security hazard.
“As a precautionary measure, the Xen Security Team has introduced fortification patches, including the incorporation of a new LOCK_HARDEN mechanism on x86 akin to the existing BRANCH_HARDEN,” asserted Xen.
“LOCK_HARDEN is deactivated by default, owing to the uncertainty surrounding the presence of a vulnerability under Xen and uncertainty regarding the performance ramifications. Nonetheless, we anticipate further research in this domain and believe it is judicious to implement a mitigation measure.”
