SledgeHammer: Amplifying Rowhammer via Bank-level Parallelism

SledgeHammer: Amplifying Rowhammer via Bank-level Parallelism

Speakers: Ingab Kang, Walter Wang, Jason Kim, Stephan van Schaik, Youssef Tobah, Daniel Genkin, Andrew Kwong, Yuval Yarom

Conference: USENIX Security '24

YouTube: https://www.youtube.com/watch?v=XpsHEtdamfc

Overview

The "SledgeHammer" talk, presented by Ingab Kang at USENIX Security '24, delves into a significant advancement in Rowhammer attacks, demonstrating how bank-level parallelism in modern DRAM (Dynamic Random-Access Memory) can be leveraged to dramatically amplify bit flips. Rowhammer, a well-known hardware vulnerability, exploits the physical proximity of memory cells, where repeatedly accessing (hammering) a row can cause charge leakage in adjacent rows, leading to bit flips. While memory manufacturers have implemented mitigations like TRResistive RAM (TRR), this research shows that these defenses can be circumvented, particularly on newer hardware generations and under default operating conditions, posing a renewed and amplified threat to system integrity.

This research introduces multibank hammering, a novel technique that exploits the independent operation of multiple memory banks to bypass timing constraints and achieve a significantly higher rate of row activations. The implications are profound: the talk demonstrates not only the increased ease of triggering Rowhammer but also its practical exploitation to gain root access on Intel 12th generation processors and achieve the first DDR4 Rambleed attack. Furthermore, "SledgeHammer" presents a groundbreaking end-to-end Rowhammer attack capable of operating within web browsers under default configurations, negating the need for specialized memory settings or privileged instructions. This work is critical for security researchers, hardware designers, and software developers, highlighting a persistent and evolving vulnerability that demands re-evaluation of current memory security paradigms.

Background

▶ Watch: Introduction: Rowhammer, mitigations, and new challenges (0:00)

To understand the "SledgeHammer" attack, it's essential to first grasp the fundamental mechanics of DRAM operation and the Rowhammer vulnerability. DRAM stores data in tiny capacitors arranged in rows and columns. To access data in a specific row, that row must first be "activated" by bringing its contents into the bitline sense amplifiers (BLSA). If a different row within the same bank needs to be accessed, the currently active row must first be "pre-charged" (evicted from the BLSA) before the new row can be activated. This sequence of activate-precharge-activate within a single bank introduces a minimum time delay known as tRC (Row Cycle Time), which limits the rate at which a single bank can be hammered.

The Rowhammer vulnerability arises from this physical process. Repeatedly activating a DRAM row (known as the "aggressor row") can cause electrical interference or charge leakage in physically adjacent rows (the "victim rows"). If an aggressor row is hammered sufficiently many times before the victim row's capacitor can be refreshed, the charge leakage can become critical, leading to a spontaneous bit flip – a 0 changing to a 1, or vice versa. This unintended data alteration can have severe security implications, as it allows an attacker to corrupt critical system data, bypass security mechanisms, or even gain elevated privileges.

Early Rowhammer attacks typically relied on hammering two adjacent rows, often in an "activator-activator" pattern (e.g., Row 0, Row 2, Row 0, Row 2...). Manufacturers responded by implementing hardware mitigations, most notably TRR, which monitors frequently activated rows and proactively refreshes them to prevent bit flips. However, subsequent research has shown that these mitigations are often insufficient. Papers like TRESpass, Blacksmith, and SMASH demonstrated "many-sided" or "all-sided" hammering patterns, where multiple aggressor rows (e.g., Row 0, Row 1, Row 2, Row 3...) are activated in rapid succession. By hammering more rows simultaneously, these attacks could sometimes overwhelm or slip past TRR, successfully inducing bit flips on DDR4 memory, even if the mitigations tracked activations. A common limitation of these earlier works, however, was their reliance on specific hardware (older DDR4 generations), non-default memory configurations, or the use of privileged instructions, making them harder to launch in real-world scenarios, particularly from user space or within browser environments. The "SledgeHammer" research addresses these limitations by focusing on newer architectures, default settings, and browser-based attacks.

Key Findings

▶ Watch: Multibank hammering results: significantly increased bit flips (4:40)

The "SledgeHammer" research delivers several critical findings that significantly advance the understanding and exploitation of Rowhammer:

1. Amplified Bit Flip Rates via Multibank Hammering: The core discovery is that leveraging bank-level parallelism in DRAM dramatically amplifies the rate of bit flips. By activating rows in different, independent memory banks concurrently, the tRC timing constraint for single-bank operations is bypassed. On an Intel i7-7700 processor with DDR4 memory, four-bank hammering generated 8x more bit flips per iteration compared to baseline single-bank hammering. More significantly, on a 12th generation Intel processor with DDR4 memory, two-bank hammering successfully generated 19 bit flips per every thousand iterations, whereas single-bank hammering failed to produce any bit flips at all. This demonstrates the technique's effectiveness on newer hardware where traditional Rowhammer might be mitigated.

1. Rapid Root Access through Sudo Op Flipping: The increased bit flip rate facilitated a much faster and more reliable privilege escalation. By optimizing the attack and leveraging multibank hammering, the researchers were able to gain root access through a sudo op flipping attack within "a few minutes." This represents "orders of magnitude speed up" compared to previous attempts, highlighting the severe practical implications of amplified Rowhammer.

1. First DDR4 Rambleed Attack: "SledgeHammer" achieved the first successful Rambleed attack on DDR4 memory. Rambleed is a side-channel attack that exploits Rowhammer-induced bit flips to leak data from adjacent memory rows, effectively enabling an attacker to read data they shouldn't have access to. The attack was demonstrated at a rate of 1.56 bits per second (BPS), proving that data exfiltration through Rowhammer is a tangible threat on modern DDR4 systems.

1. Browser-Based Rowhammer on Default Settings: A groundbreaking achievement is the successful execution of Rowhammer attacks from within web browsers (both Chrome and Firefox) under default configurations. This bypasses the need for special settings like Transparent Huge Pages (THP), which previous browser-based Rowhammer attacks often required.

• On Chrome, the attack generated 169 bit flips per hour.
• On Firefox, it generated 107 bit flips per hour.

The research also achieved an end-to-end write primitive on Firefox, demonstrating the ability to not just flip bits, but to control which bits are flipped, which is crucial for practical exploitation. This was accomplished by utilizing a 2 megabyte continuous memory detection side channel to overcome the limitations of memory allocation in browsers.

These findings collectively illustrate that Rowhammer remains a critical and evolving threat, with multibank hammering effectively circumventing existing mitigations and expanding the attack surface to widely used environments like web browsers, even on contemporary hardware.

Technical Deep Dive

▶ Watch: Gaining root access via sudu op flipping attack (5:30)

The "SledgeHammer" attack fundamentally re-architects the Rowhammer hammering pattern to exploit bank-level parallelism in DRAM. Traditional Rowhammer attacks, often termed single-bank hammering, involve repeatedly activating two or more rows within the same DRAM bank. For example, an aggressor pattern might be Activate Row 0, Pre-charge, Activate Row 2, Pre-charge, Activate Row 0, and so on. The crucial timing constraint here is tRC (Row Cycle Time), the minimum time required between two consecutive Activate commands within the same bank. This tRC value limits how quickly a single bank can be hammered, providing an opportunity for hardware mitigations like TRR to detect and refresh frequently accessed rows.

"SledgeHammer" introduces multibank hammering to bypass this tRC limitation. DRAM is organized into multiple independent banks, where operations in one bank do not directly interfere with operations in another, except for shared resources like the memory bus. The core idea is to activate a row in Bank A, then immediately activate a row in Bank B, then Bank C, Bank D, and so on, before returning to activate another row in Bank A. This allows the memory controller to issue Activate commands to different banks in rapid succession, effectively keeping the memory bus busy and increasing the overall rate of row activations across the entire DRAM module. The talk illustrates this with an example of hammering 12 different rows across four different banks, which is "a lot more paralyzed" than single-bank approaches. This parallel activation strategy results in a significantly higher number of total Activate commands issued per unit of time, overwhelming TRR mechanisms that might be designed to track tRC-limited activations within individual banks.

The technical challenge of launching Rowhammer attacks from within a web browser is particularly complex due to the absence of direct memory control and cache management instructions. Traditional Rowhammer attacks in native code often rely on instructions like clflush to evict data from the CPU cache, ensuring that memory accesses always go to the DRAM and trigger row activations. In browsers, clflush is unavailable. The naive approach to cache eviction in browsers is to use eviction sets: repeatedly access different memory addresses that map to the same CPU cache set. When the cache set is full, accessing another address for that set will evict an existing entry, forcing a memory access. However, as the talk explains, this is "highly inefficient," often requiring seven memory accesses to achieve a single row activation in DRAM, making it difficult to generate enough activations to trigger bit flips (previous work, SMASH, achieved "under three bit flips per hour" with this method).

Multibank hammering provides an elegant solution to the browser cache problem. By having access to "a lot more addresses to play with" (due to the multiple banks), the attack can strategically fill the CPU cache ways with addresses that correspond to the aggressor rows across different banks. When the cache is full, subsequent memory accesses to any of these aggressor rows (which are designed to map to the same cache sets) will cause an eviction of another aggressor row from the cache. This creates a highly efficient 1:1 trade-off: one memory access from the browser directly translates to one row activation in DRAM. This efficiency, combined with the parallel hammering across banks, allows "SledgeHammer" to generate a significantly higher rate of row activations (169 flips per hour on Chrome, 107 flips per hour on Firefox) within the browser environment, far surpassing previous attempts.

Furthermore, a key aspect of making browser attacks practical on default settings is overcoming the reliance on Transparent Huge Pages (THP). Previous browser-based Rowhammer attacks often required THP to be enabled to allocate large, contiguous blocks of memory, which are necessary to reliably find and hammer adjacent rows. "SledgeHammer" negates this need by utilizing a 2 megabyte continuous memory detection side channel. While the talk does not delve into the specifics of this side channel, its purpose is to enable the attacker to locate and utilize contiguous memory regions within the browser's allocated memory, even without the explicit use of THP. This allows the attack to identify suitable aggressor/victim row pairs, making the attack viable in a wider range of default browser configurations.

Demo / Proof of Concept

▶ Watch: First DDR4 Rambleed: reading data from neighboring rows (5:50)

While the talk did not feature a live, real-time demonstration during the presentation, it thoroughly detailed and presented the results of several compelling proofs of concept (PoCs) that validate the efficacy and practical exploitability of the "SledgeHammer" techniques. These PoCs moved beyond mere bit flip observation to demonstrate concrete security impacts.

One of the most critical demonstrations was the sudo op flipping attack used to achieve root access. The researchers successfully leveraged the amplified bit flip rates generated by multibank hammering to corrupt a critical memory region associated with the sudo utility. By flipping specific bits in the sudoers file or related data structures, they could bypass authentication checks or modify user privileges. The talk highlighted that this attack was achieved "after a few minutes," representing an "orders of magnitude speed up" compared to prior Rowhammer-based privilege escalation attempts. This showcases the significant practical threat posed by "SledgeHammer" in achieving high-privilege access on vulnerable systems.

The research also presented the first successful Rambleed attack on DDR4 memory. Rambleed is a sophisticated side-channel attack where Rowhammer-induced bit flips are used to infer data from physically adjacent memory rows without direct read access. The PoC demonstrated the ability to read data at a rate of 1.56 bits per second (BPS). This means an attacker could, with sufficient time, reconstruct sensitive information (e.g., encryption keys, user data) that resides in memory regions adjacent to the attacker-controlled aggressor rows, even if those regions are protected by memory isolation mechanisms. The successful demonstration on DDR4 memory is significant, as previous Rambleed variants primarily targeted older DDR3 memory.

Finally, the talk provided a robust demonstration of browser-based Rowhammer attacks running within Google Chrome and Mozilla Firefox under default configurations. The researchers showcased that their multibank hammering technique, combined with a novel cache eviction strategy and a 2 MB continuous memory detection side channel, could consistently induce bit flips. They reported 169 bit flips per hour on Chrome and 107 bit flips per hour on Firefox. Beyond just flipping bits, the PoC extended to achieving an end-to-end write primitive on Firefox. This is a crucial step for practical exploitation, as a reliable write primitive allows an attacker to precisely control memory contents, which is often a prerequisite for injecting malicious code or altering program execution flow. The ability to achieve these results without relying on Transparent Huge Pages (THP) or other non-default settings underscores the broad applicability and immediate relevance of this vulnerability to everyday users.

Defensive Implications

▶ Watch: Overcoming browser cache limitations with multibank hammering (8:00)

The "SledgeHammer" research presents significant challenges for current and future DRAM security, necessitating a re-evaluation of existing Rowhammer mitigations and the development of more robust defenses.

The primary defensive implication is that current hardware-based mitigations, particularly those like TRResistive RAM (TRR), are demonstrably insufficient against attacks leveraging bank-level parallelism. TRR typically monitors the activation rate of individual rows or banks. By distributing the hammering across multiple independent banks, "SledgeHammer" can bypass the tRC timing constraint for individual banks, allowing for a higher cumulative rate of Activate commands. This "distributed" hammering likely falls below the threshold for any single bank's TRR counter, even as the overall stress on adjacent cells increases dramatically. Memory manufacturers must develop new TRR algorithms or hardware designs that can detect and mitigate parallel hammering patterns across multiple banks, rather than focusing solely on single-bank activity. This might involve more global monitoring of the memory controller's command queue or more sophisticated statistical analysis of activation patterns across the entire DRAM module.

The successful exploitation on Intel 12th generation processors with DDR4 memory is a clear indicator that newer hardware generations are not inherently immune to Rowhammer, especially when advanced hammering techniques are employed. This contradicts an implicit assumption that newer memory controllers or DRAM designs might naturally mitigate the issue. Hardware vendors need to acknowledge that Rowhammer is an ongoing architectural challenge, not a legacy bug, and must integrate more resilient defenses into future designs (e.g., DDR5, DDR6). This could involve physical isolation improvements between memory cells, more aggressive refresh rates, or dynamic voltage adjustments.

The demonstration of browser-based Rowhammer attacks on default configurations significantly broadens the attack surface. Previously, browser-based attacks often required specific, non-default system settings like Transparent Huge Pages (THP), which limited their real-world applicability. "SledgeHammer" shows that malicious JavaScript or WebAssembly code, running within a standard web browser, can now reliably trigger Rowhammer bit flips and even achieve write primitives. This implies that any website could potentially host such an attack, affecting a vast number of users without requiring any special setup on their part. Browser developers (e.g., Chrome, Firefox) must consider implementing stricter memory allocation policies, more aggressive memory sanitization, or even timing-based side-channel mitigations to prevent the precise memory access patterns required for Rowhammer. Operating systems could also implement stronger memory isolation or randomization techniques to make it harder for attackers to locate contiguous memory regions and predict physical memory layouts.

Finally, the achievement of root access via sudo op flipping and the DDR4 Rambleed attack underscore the severe consequences of Rowhammer. These are not merely academic curiosities but concrete pathways to privilege escalation and data exfiltration. This calls for a multi-layered defense strategy involving both hardware and software. At the operating system level, critical data structures and security-sensitive binaries should be protected with memory regions that are either explicitly shielded from Rowhammer (if such a mechanism becomes available) or are allocated in a highly randomized fashion to prevent predictable aggressor/victim relationships. Software developers should also adopt practices that minimize the storage of sensitive information in predictable memory locations and consider using memory-safe languages or techniques to reduce the impact of memory corruption vulnerabilities.

Key Takeaways

• Bank-level parallelism is a powerful new vector for Rowhammer attacks, allowing attackers to bypass tRC timing constraints and current hardware mitigations.
• "SledgeHammer" significantly amplifies bit flip rates, achieving 8x more bit flips on Intel i7-7700 and 19 bit flips per 1000 iterations on 12th Gen Intel processors with DDR4, where single-bank hammering failed.
• The amplified bit flips enable rapid and practical exploitation, demonstrated by achieving root access via sudo op flipping within minutes and the first DDR4 Rambleed attack at 1.56 BPS.
• Rowhammer attacks are now viable within web browsers (Chrome, Firefox) on default settings, without requiring Transparent Huge Pages (THP), broadening the attack surface significantly.
• Existing hardware mitigations like TRR need urgent re-evaluation and redesign to account for multibank hammering patterns, as they are currently insufficient.
• Hardware manufacturers must integrate more robust, architectural defenses against Rowhammer into future DRAM generations, recognizing it as an ongoing threat.

About the Speaker(s)

The "SledgeHammer" talk was primarily presented by Ingab Kang. Ingab Kang is one of the key researchers behind this work, which involved a collaborative effort from a team of academics and security experts. The co-authors listed for this paper include Walter Wang, Jason Kim, Stephan van Schaik, Youssef Tobah, Daniel Genkin, Andrew Kwong, and Yuval Yarom. While specific affiliations were not provided in the transcript, the context of a USENIX Security conference suggests that these individuals are likely researchers and academics specializing in computer security, hardware vulnerabilities, and memory systems from various institutions. Their collective expertise has been instrumental in uncovering and demonstrating these advanced Rowhammer exploitation techniques.