A new data leak vulnerability known as GhostRace affects modern CPUs.

A new data leak vulnerability known as GhostRace affects modern CPUs.

Modern CPU architectures that facilitate speculative execution are now susceptible to a novel data leakage attack, as identified by a group of researchers.

It is a variant of the transient execution CPU flaw Spectre v1, which is referred to as GhostRace (CVE-2024-2193). Race conditions and speculative execution are incorporated into the strategy.

ChatGPT Plugins from Third Parties Might Facilitate Account Takeovers.

“All the common synchronization primitives implemented using conditional branches can be microarchitecturally bypassed on speculative paths using a branch misprediction attack, turning all architecturally race-free critical regions into Speculative Race Conditions (SRCs), allowing attackers to leak information from the target,” according to the researchers.

The results obtained from the Systems Security Research Group at IBM Research Europe and VUSec, with the latter revealing in December 2023 an additional side-channel attack known as SLAM that specifically targets contemporary processors.

Spectre is a category of side-channel attacks that circumvent isolation protections between applications by reading privileged data from the memory using branch prediction and speculative execution on modern CPUs.

Although the majority of central processing units (CPUs) employ speculative execution as a means of optimizing performance, Spectre attacks exploit the fact that incorrect predictions leave traces of memory accesses or computations in the caches of the processor.

“Spectre attacks induce a victim to speculatively perform operations that would not occur during strictly serialized in-order processing of the program’s instructions, and which leak victim’s confidential information via a covert channel to the adversary,” the investigators who conducted the Spectre attack reported in January 2018.

GhostRace is significant due to the fact that it permits an unauthenticated assailant to retrieve arbitrary data from the processor by exploiting Speculative Concurrent Use-After-Free (SCUAF) attacks and race conditions to gain access to the speculative executable code paths.

A race condition is an undesirable circumstance that arises when multiple processes attempt to access a shared resource at the same time without appropriate synchronization. This creates inconsistent outcomes and provides an adversary with an opportunity to execute malicious actions.

The CERT Coordination Center (CERT/CC) explained in an advisory that an SRC vulnerability is “similar to a classic race condition in terms of characteristics and exploitation strategy.”

“However, it is different in that the attacker exploits said race condition on a transiently executed path originating from a mis-speculated branch (similar to Spectre v1), targeting a racy code snippet or gadget that ultimately discloses information to the attacker.”

As a consequence, an adversary with CPU resource access is granted the ability to retrieve arbitrary sensitive data from the host memory.

“Any software, e.g., operating system, hypervisor, etc., implementing synchronization primitives through conditional branches without any serializing instruction on that path and running on any microarchitecture (e.g., x86, ARM, RISC-V, etc.), which allows conditional branches to be speculatively executed, is vulnerable to SRCs,” VUSec stated.

Dover Harbour Board and Kent Police are reprimanded by the ICO for sharing information.

AMD stated that its prior guidance for Spectre “remains applicable to mitigate this vulnerability” subsequent to the responsible disclosure. While acknowledging that all versions are affected, the maintainers of the Xen open-source hypervisor stated that the vulnerability is unlikely to pose a significant security risk.

“Out of caution, the Xen Security Team have provided hardening patches including the addition of a new LOCK_HARDEN mechanism on x86 similar to the existing BRANCH_HARDEN,” according to Xen.

“LOCK_HARDEN is deactivated by default due to the unpredictability of a Xen vulnerability and the uncertainty surrounding its performance impact.” Nevertheless, further investigation is anticipated in this field, and we believe it is judicious to establish a mitigation strategy.”


Scroll to Top