Mar 28, 2024NewsroomHardware Security / Vulnerability

Cybersecurity researchers from ETH Zurich have developed a new variant of the RowHammer DRAM (dynamic random-access memory) attack that, for the first time, successfully works against AMD Zen 2 and Zen 3 systems despite mitigations such as Target Row Refresh (TRR).

“This result proves that AMD systems are equally vulnerable to Rowhammer as Intel systems, which greatly increases the attack surface, considering today’s AMD market share of around 36% on x86 desktop CPUs,” the researchers said.

The technique has been codenamed ZenHammer, which can also trigger RowHammer bit flips on DDR5 devices for the first time.

RowHammer, first publicly disclosed in 2014, is a well-known attack that exploits DRAM’s memory cell architecture to alter data by repeatedly accessing a specific row (aka hammering) to cause the electrical charge of a cell to leak to adjacent cells.

This can induce random bit flips in neighboring memory rows (from 0 to 1, or vice versa), which can alter the memory contents and potentially facilitate privilege escalation, compromising system credentials, integrity, and availability of a system.

The attacks take advantage of the physical proximity of these cells within the memory array, a problem that’s likely to worsen as the DRAM technology scaling continues and the storage density increases.

“As DRAM continues to scale, RowHammer bit flips can occur at smaller activation counts and thus a benign workload’s DRAM row activation rates can approach or even exceed the RowHammer threshold,” ETH Zurich researchers noted in a paper published in November 2022.

“Thus, a system may experience bit flips or frequently trigger RowHammer defense mechanisms even without a malicious party performing a RowHammer attack in the system, leading to data corruption or significant performance degradation.”

One of the crucial mitigations implemented by DRAM manufacturers against RowHammer is TRR, which is an umbrella term used for mechanisms that refresh target rows that are determined to be accessed frequently.

In doing so, the idea is to generate more memory refresh operations so that victim rows will either be refreshed before bits are flipped or be corrected after bits are flipped due to RowHammer attacks.

ZenHammer, like TRRespass and SMASH, bypasses TRR guardrails by reverse engineering the secret DRAM address functions in AMD systems and adopting improved refresh synchronization and scheduling of flushing and fencing instructions to trigger bit flips on seven out of 10 sample Zen 2 devices and six out of 10 Zen 3 devices.

The study also arrived at an optimal hammering instruction sequence to improve row activation rates in order to facilitate more effective hammering.

“Our results showed that regular loads (MOV) with CLFLUSHOPT for flushing aggressors from the cache, issued immediately after accessing an aggressor (‘scatter’ style), is optimal,” the researchers said.

ZenHammer has the distinction of being the very first method that can trigger bit flips on systems equipped with DDR5 chips on AMD’s Zen 4 microarchitectural platform. That said, it only works on one of the 10 tested devices (Ryzen 7 7700X).

It’s worth noting that DDR5 DRAM modules were previously considered immune to RowHammer attacks owing to them replacing TRR with a new kind of protection called refresh management.

“The changes in DDR5 such as improved RowHammer mitigations, on-die error correction code (ECC), and a higher refresh rate (32 ms) make it harder to trigger bit flip,” the researchers said.

“Given the lack of bit flips on nine of 10 DDR5 devices, more work is needed to better understand the potentially new RowHammer mitigations and their security guarantees.”

AMD, in a security bulletin, said it’s assessing RowHammer bit flips on DDR5 devices, and that it will provide an update following its completion.

“AMD microprocessor products include memory controllers designed to meet industry-standard DDR specifications,” it added. “Susceptibility to RowHammer attacks varies based on the DRAM device, vendor, technology, and system settings.”

Mar 15, 2024NewsroomHardware Security / Data Protection

A group of researchers has discovered a new data leakage attack impacting modern CPU architectures supporting speculative execution.

Dubbed GhostRace (CVE-2024-2193), it is a variation of the transient execution CPU vulnerability known as Spectre v1 (CVE-2017-5753). The approach combines speculative execution and race conditions.

“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,” the researchers said.

The findings from the Systems Security Research Group at IBM Research Europe and VUSec, the latter of which disclosed another side-channel attack called SLAM targeting modern processors in December 2023.

Spectre refers to a class of side-channel attacks that exploit branch prediction and speculative execution on modern CPUs to read privileged data in the memory, bypassing isolation protections between applications.

While speculative execution is a performance optimization technique used by most CPUs, Spectre attacks take advantage of the fact that erroneous predictions leave behind traces of memory accesses or computations in the processor’s caches.

“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 researchers behind the Spectre attack noted in January 2018.

What makes GhostRace notable is that it enables an unauthenticated attacker to extract arbitrary data from the processor using race conditions to access the speculative executable code paths by leveraging what’s called a Speculative Concurrent Use-After-Free (SCUAF) attack.

A race condition is an undesirable situation that occurs when two or more processes attempt to access the same, shared resource without proper synchronization, thereby leading to inconsistent results and opening a window of opportunity for an attacker to perform malicious actions.

“In characteristics and exploitation strategy, an SRC vulnerability is similar to a classic race condition,” the CERT Coordination Center (CERT/CC) explained in an advisory.

“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.”

The net result is that it permits an attacker with access to CPU resources to access arbitrary sensitive data from 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 said.

Following responsible disclosure, AMD said its existing guidance for Spectre “remains applicable to mitigate this vulnerability.” The maintainers of the Xen open-source hypervisor acknowledged that all versions are impacted, although they said it’s unlikely to pose a serious security threat.

“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,” Xen said.

“LOCK_HARDEN is off by default, owing to the uncertainty of there being a vulnerability under Xen, and uncertainty over the performance impact. However, we expect more research to happen in this area, and feel it is prudent to have a mitigation in place.”