Posthammer: Pervasive Browser-based Rowhammer Attacks with Postponed Refresh Commands

Posthammer: Pervasive Browser-based Rowhammer Attacks with Postponed Refresh Commands

Speakers: Finn de Ridder, Computer Security Group, ETH Zurich

Conference: USENIX Security

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

Overview

The "Posthammer" talk at USENIX Security unveiled a sophisticated and highly effective browser-based Rowhammer attack that significantly expands the attack surface for this persistent memory vulnerability. Presented by Finn de Ridder, this research demonstrates that a majority of modern DDR4 memory chips are susceptible to Rowhammer-induced bit flips initiated directly from a web browser. The talk highlights novel techniques, including the exploitation of postponed refresh commands and the creation of non-uniform hammering patterns using browser-accessible primitives, to bypass existing hardware mitigations.

The implications of Posthammer are substantial. By achieving a reliable read/write primitive within the JavaScript process, an attacker can gain significant control over the browser's memory space, potentially leading to arbitrary code execution or data exfiltration. The research showcases a practical attack that takes approximately 15 minutes on average with a 40% success rate on 17 out of 28 tested DIMMs, underscoring the severity and widespread applicability of these new techniques against contemporary memory hardware.

This work not only re-emphasizes the enduring threat of Rowhammer but also pushes the boundaries of browser-based exploitation. It reveals critical weaknesses in the current memory subsystem design and existing mitigations, particularly concerning the flexibility allowed for refresh command scheduling and the inability of mitigations to effectively counter complex, non-uniform hammering patterns. The findings call for a re-evaluation of memory security architectures and browser-level defenses to adequately address these advanced attack vectors.

Background

▶ Watch: Introduction and pervasive browser-based Rowhammer vulnerability (0:00)

The Rowhammer vulnerability, first publicly disclosed in 2014, is a hardware design flaw in modern DRAM modules where repeatedly accessing (hammering) a row of memory can cause electrical interference that flips bits in physically adjacent rows. This phenomenon arises because DRAM cells are packed very densely, and repeated activation of one row can induce charge leakage in neighboring, unaccessed rows. Rowhammer poses a significant security risk because these bit flips can be exploited to bypass security mechanisms, escalate privileges, or achieve arbitrary code execution.

Early Rowhammer attacks typically required native code execution to achieve the precise and rapid memory accesses necessary to trigger bit flips. These attacks often relied on instructions like clflush to bypass CPU caches and ensure memory accesses directly hit DRAM. In response, memory manufacturers and system designers implemented various mitigations, primarily Target Row Refresh (TRR), which attempts to identify frequently hammered rows and proactively refresh their neighbors. These mitigations often rely on the assumption of uniform hammering patterns and a strict periodicity of DRAM refresh commands.

However, the threat evolved with the advent of browser-based Rowhammer attacks. These attacks leverage web technologies, particularly JavaScript, to induce Rowhammer. The challenge in a browser environment is the lack of direct memory access control and the inability to use privileged instructions like clflush. Attackers must instead rely on cache eviction sets – carefully crafted sets of memory addresses that, when accessed, force other specific addresses out of the CPU cache, thereby guaranteeing that subsequent accesses to those evicted addresses hit DRAM. Previous browser-based attacks often struggled with the speed and complexity required to trigger Rowhammer reliably and to bypass newer mitigations, frequently resulting in slower, less effective, and uniform hammering patterns. The difficulty lay in generating the high-frequency, targeted DRAM accesses needed for Rowhammer without native control, and doing so in a way that could evade the ever-improving hardware mitigations.

Key Findings

▶ Watch: Insight 2: Non-uniform Rowhammer patterns are more effective (2:00)

The Posthammer research introduces several critical insights that collectively enable pervasive browser-based Rowhammer attacks:

1. Exploitation of Postponed Refresh Commands: A fundamental finding is that the DRAM standard allows memory controllers to postpone refresh commands. While mitigations like TRR rely on the periodic nature of refreshes to reset internal counters and prevent bit flips, attackers can exploit this flexibility. By inducing a scenario where refresh commands are delayed, the attacker can create periods of "mitigation inactivity," during which they can hammer freely and more effectively, significantly boosting the attack's success rate.

1. Effectiveness of Non-Uniform Rowhammer Patterns: The research demonstrates that non-uniform Rowhammer patterns are significantly more effective than uniform ones. Unlike uniform patterns where all aggressor rows are hammered equally, non-uniform patterns involve different aggressors targeting different rows with varying frequencies. This makes it challenging for mitigations, which often must choose specific aggressors to mitigate, to stop all hammering activity.

1. Browser-Based Non-Uniform Pattern Generation with "Lanes": A key contribution is the development of a technique to generate fast and non-uniform Rowhammer patterns from within the browser context. This is achieved through the novel concept of "lanes," which are constructed using minimal eviction sets. By carefully chaining these lanes, attackers can control the relative hammering frequency of different aggressors, overcoming the browser's limitations in direct memory access and complex pattern generation.

1. Generic and Pervasive Attack Template: The research found that a surprisingly small number of generic and very strong patterns are sufficient to bypass all existing mitigations on a wide range of DIMMs. This means attackers do not need to tailor their patterns to specific memory chips but can use a template that, with minor adjustments, reliably triggers bit flips on most vulnerable hardware. The study showed that 17 out of 28 tested DIMMs were vulnerable using this approach.

1. Practicality and Exploit Primitive: The Posthammer attack is highly practical, achieving an average attack time of 15 minutes and a 40% success rate. Crucially, it culminates in obtaining a read/write primitive within the JavaScript process, allowing an attacker to read from and write to arbitrary memory locations in the browser's address space. This primitive is a stepping stone to more severe consequences, such as arbitrary code execution.

Technical Deep Dive

▶ Watch: Browser challenge: Creating non-uniform patterns without clflush (2:40)

The technical prowess of Posthammer lies in its multi-pronged approach to overcoming the inherent limitations of browser-based attacks and existing Rowhammer mitigations.

Refresh Postponement

Traditional Rowhammer mitigations, such as TRR, are predicated on the assumption that DRAM refresh commands are issued periodically and predictably. These refreshes serve to reset internal counters that track hammering activity and proactively refresh neighboring rows. However, the JEDEC standard for DDR allows memory controllers a degree of flexibility in scheduling these refreshes. Specifically, refresh commands can be postponed for a certain duration. Posthammer exploits this overlooked flexibility. By executing specific memory access patterns, the attacker can induce the memory controller to delay these critical refresh operations. This creates a window of "mitigation inactivity" where the Rowhammer counter is not reset, allowing the attacker to hammer target rows with increased intensity and duration, thereby significantly increasing the probability of bit flips. This insight is foundational, as it undermines the core assumption of many hardware-based Rowhammer defenses.

Eviction Sets and Lane Construction for Non-Uniformity

Generating effective Rowhammer patterns from a browser requires bypassing CPU caches to ensure memory accesses hit DRAM. This is achieved using eviction sets.

• Traditional Eviction Sets: In a basic eviction set, an aggressor address is placed in a cache set. To evict it, many other addresses mapping to the same cache set are accessed, pushing the aggressor out. Subsequent accesses to the aggressor then go to DRAM. This method is slow because all accesses are cache misses and hit DRAM, and it produces a uniform hammering pattern.
• Minimal Eviction Sets: To improve speed, the Posthammer technique uses minimal eviction sets. Here, only one additional address is needed to evict the aggressor. While faster, all accesses still hit DRAM, and the pattern remains uniform.
• Cache Hits for Performance: Further optimization involves using cache hits. By accessing certain addresses more frequently, they are "pinned" to the cache, resulting in faster operations. This reduces the number of DRAM accesses but still typically yields a uniform hammering pattern with two addresses hitting DRAM (the aggressor and one other for eviction).

The critical innovation for achieving non-uniformity is the concept of lanes. A lane is a minimal eviction set designed to hammer a specific aggressor. The challenge is that a single lane, by itself, creates a uniform pattern. To introduce non-uniformity, Posthammer chains multiple lanes together. The key constraint is that the same lane cannot be repeated twice consecutively; the aggressor must be alternated.

Consider an example:

• Lane 1: Hammers Aggressor A.
• Lane 2: Hammers Aggressor B.
• Lane 3: Hammers Aggressor C.

By chaining these lanes as Lane1 -> Lane2 -> Lane1 -> Lane3, Aggressor A is hammered twice, while Aggressors B and C are hammered only once. This creates a non-uniform pattern (e.g., 50% for A, 25% for B, 25% for C). This technique allows for the creation of complex, fast, and non-uniform patterns that are difficult for hardware mitigations to detect and prevent effectively, as they are often designed to counter simpler, uniform access patterns. The talk highlights that many such combinations are possible, enabling fine-grained control over hammering ratios.

The Generic and Strong Pattern

To achieve widespread success across different DIMMs, Posthammer employs a generic and very strong pattern that combines uniform hammering for intensity with non-uniform elements for mitigation distraction. This pattern is structured as follows:

1. Uniform Part: The pattern begins with a repeating sequence of two lanes, each containing two aggressors. This part hammers intensively and uniformly. While effective for inducing bit flips, a standalone uniform pattern would typically be detected by mitigations.
2. Non-Uniform Distraction Part: To bypass mitigations, several "extra lanes" (e.g., B1, B2, B3) are added. These lanes contain multiple aggressors but are not intended for heavy hammering. Instead, their purpose is to introduce significant non-uniformity and complexity into the access pattern, effectively "distracting" the mitigation logic. The mitigation system, faced with numerous aggressors and varying access frequencies, struggles to identify and counter the primary hammering activity.

These five lanes (two from the uniform part, three extra) are connected into a single pointer chase. A pointer chase is a sequence of memory accesses where each access retrieves the address of the next access. This ensures that the entire pattern is executed in a continuous and rapid manner, maximizing the hammering effect. When this sophisticated pattern is combined with the exploitation of refresh postponement, it becomes highly effective, capable of triggering bit flips on most vulnerable DIMMs.

Demo / Proof of Concept

▶ Watch: Introducing "Lanes" for browser-based non-uniform Rowhammer (6:50)

The Posthammer proof of concept culminates in a powerful exploit that achieves an arbitrary read/write primitive within the JavaScript process of a victim's browser. This is a critical step towards full code execution. The core idea behind the exploit is type flipping, where Rowhammer-induced bit flips are used to manipulate the type tags of JavaScript objects, fundamentally changing their interpretation by the JavaScript engine. Specifically, the attack aims to flip bits that transform array references into floating-point numbers and vice-versa.

The exploit unfolds in a complex, 10-step process:

1. Allocator Exhaustion: The attack begins by allocating a large amount of memory. This forces the memory allocator to split larger blocks, making it easier to obtain contiguous memory. Contiguous memory is crucial for constructing reliable eviction sets.
2. Build One Eviction Set: Using the newly acquired contiguous memory, the attacker builds an initial eviction set. This first set is foundational for the subsequent steps.
3. Build Many Eviction Sets: Once one eviction set is established, it can be leveraged to build many more, even without requiring contiguous memory for each subsequent set. This provides the necessary infrastructure for complex hammering patterns.
4. Hammering: The attacker then begins hammering using the sophisticated, non-uniform patterns discussed earlier. Slight variations are employed, and eviction sets are constantly swapped to search for exploitable bit flips.
5. Identify Exploitable Bit Flips: The exploit requires very specific bit flips: a 0-to-1 bit flip and a 1-to-0 bit flip at precise memory locations. These are "particular bit flips" that are crucial for the subsequent type confusion.
6. Prevent Undesired Bit Flips ("Soft Hammer"): Since hammering often triggers many bit flips, the attacker needs to selectively trigger only the desired ones. This is achieved using a technique called soft hammer, where other, undesired bit flips are "softly hammered" to prevent them from occurring, ensuring the integrity of surrounding data while focusing on the target bit flips.
7. Release & Reallocate: The attacker-owned arrays that were hammered are then freed. Immediately afterward, target arrays are allocated. The goal is for the previously induced bit flips to "land" in these newly allocated target arrays. This step has a reported success rate of about 80%.
8. Locate Bit Flips: The attacker hammers again to precisely identify where in the target arrays the exploitable bit flips have occurred.
9. Trigger Type Flipping: Now, the identified bit flips are actively used.

• The first 0-to-1 bit flip is triggered, which turns a JavaScript array into a floating-point number.
• The 1-to-0 bit flip is then used to convert the floating-point number into a string reference.
• Finally, the same 0-to-1 bit flip is re-triggered to create a valid but fake JavaScript array. The attacker now controls the internal structure of this fake array.

1. Achieve Read/Write Primitive: By controlling the data pointer of this fake array, the attacker gains the ability to read and write anywhere in the address space of the JavaScript process. This is the arbitrary read/write primitive, which is completely "free of huge pages" and "pretty reliable." The overall success rate of the entire exploit chain is reported at 40%. The speaker notes that failures usually occur due to too many undesired bit flips corrupting critical data, leading to a crash. The artifact for the attack is available and encouraged for review.

Defensive Implications

▶ Watch: Insight 3: Few generic patterns bypass all mitigations (8:30)

The Posthammer research highlights several critical areas where current defenses against Rowhammer are insufficient, necessitating a multi-layered approach to security:

1. DRAM Refresh Mechanisms: The primary takeaway is that existing DRAM refresh rates and the flexibility in refresh command postponement are exploitable.

• Increased Refresh Rates: A straightforward, albeit performance-impacting, defense would be to increase the refresh rate of DRAM. However, this comes with power and performance penalties.
• Dynamic/Adaptive Refresh: More sophisticated adaptive refresh mechanisms could dynamically adjust refresh rates based on detected access patterns, but these need to be robust enough to detect complex, non-uniform patterns without being bypassed.
• Stricter Refresh Scheduling: Memory controllers should be designed to reduce or eliminate the ability to postpone refresh commands, making their execution more predictable and reducing the attacker's window of opportunity.

1. Hardware-Software Co-Design: The problem is not solely a hardware issue; software also plays a role.

• Memory Allocator Hardening: Browser and operating system memory allocators should be hardened to reduce the likelihood of obtaining contiguous memory blocks that are easily exploitable for eviction set construction. Randomization of allocations and increased fragmentation could make it harder for attackers to set up their hammering infrastructure.
• Pointer Integrity/Tagging: JavaScript engines and other runtime environments could implement stronger pointer integrity checks or memory tagging to detect and prevent type confusion attacks that rely on manipulating object type tags or data pointers.

1. Browser Security:

• Precise Timing Attack Mitigation: The construction of eviction sets and the exploitation of refresh postponement rely heavily on precise timing. Browsers need to continue to harden against side-channel attacks that allow for high-resolution timers or other means of inferring memory access patterns and timing. This includes reducing timer precision, introducing noise, and isolating processes.
• JavaScript Engine Hardening: Beyond pointer integrity, JavaScript engines should implement more robust checks to validate object types before performing operations, making it harder to exploit bit-flip induced type confusion. This includes stronger garbage collection mechanisms that can detect corrupted objects.
• Process Isolation: Further isolation of browser processes and tabs could limit the impact of a successful Rowhammer attack, preventing it from immediately affecting other parts of the system or other web pages.

1. Hardware Mitigations: Existing hardware mitigations like TRR need to evolve.

• Non-Uniform Pattern Detection: Mitigations must be capable of detecting and responding to non-uniform Rowhammer patterns and not just simple, uniform ones. This requires more sophisticated monitoring and prediction algorithms within the memory controller.
• Comprehensive Aggressor Tracking: Instead of just tracking a few aggressors, mitigations may need to track a wider range of potential aggressor rows or employ techniques that are less sensitive to the specific pattern of hammering.

1. Vulnerability Disclosure and Patching: Given the pervasiveness of the vulnerability, continuous efforts are needed for responsible disclosure, thorough testing of new DIMMs, and rapid deployment of firmware updates or software patches where feasible.

Key Takeaways

• Rowhammer remains a potent and pervasive hardware vulnerability, with modern DDR4 DIMMs still susceptible to sophisticated attacks launched from web browsers.
• The ability to exploit postponed refresh commands is a critical new enabler, creating windows of opportunity for attackers to bypass existing hardware mitigations.
• Non-uniform Rowhammer patterns, constructed using novel "lanes" from minimal eviction sets, are highly effective at evading current mitigation strategies.
• A surprisingly small set of generic hammering patterns can compromise a majority of DDR4 DIMMs, simplifying the attacker's task and broadening the attack's applicability.
• Browser-based Rowhammer attacks can achieve powerful primitives like arbitrary read/write in the JavaScript process, posing a significant risk for data exfiltration and code execution.
• Effective defense requires a multi-faceted approach, including stricter DRAM refresh scheduling, hardened memory allocators, enhanced browser security against timing attacks, and more intelligent hardware mitigations capable of detecting complex hammering patterns.

About the Speaker(s)

Finn de Ridder is a researcher from the computer security group at ETH Zurich. His work focuses on hardware security, particularly memory vulnerabilities like Rowhammer, and exploring their exploitation in various contexts, including web browsers. This talk, "Posthammer," is a collaborative effort with his colleagues Patrick and Cave from the same group.