Source-linked AI summary
Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript
Daniel Gruss, Clémentine Maurice, Stefan Mangard
TL;DR
Rowhammer attacks challenge the assumption that memory can only be modified through permitted writes, but prior attacks depended on cache flushing. This paper defeats complex cache replacement policies with regular accesses, enabling an automated remote JavaScript attack that triggers faults on vulnerable systems.
Problem
Prior Rowhammer attacks relied on a cache flush instruction, limiting attacks in restricted and scripting environments despite the security impact of DRAM bit flips.
Method
The paper explores cache eviction strategies and combines them into an automated two-phase attack for systems with unknown hardware configurations.
Results
Remote JavaScript can trigger Rowhammer bit flips through a web browser on vulnerable systems, with the implementation running in recent Firefox and Google Chrome versions.
Takeaways & Limitations
Website-delivered Rowhammer attacks pose an enormous threat because they can operate remotely and stealthily across millions of victim machines.
Takeaways & Limitations
JavaScript attacks depend on large pages and amplified single-sided hammering, and finding an exploitable bit flip can take several hours.
Abstract
from arXiv · showhide
A fundamental assumption in software security is that a memory location can only be modified by processes that may write to this memory location. However, a recent study has shown that parasitic effects in DRAM can change the content of a memory cell without accessing it, but by accessing other memory locations in a high frequency. This so-called Rowhammer bug occurs in most of today's memory modules and has fatal consequences for the security of all affected systems, e.g., privilege escalation attacks. All studies and attacks related to Rowhammer so far rely on the availability of a cache flush instruction in order to cause accesses to DRAM modules at a sufficiently high frequency. We overcome this limitation by defeating complex cache replacement policies. We show that caches can be forced into fast cache eviction to trigger the Rowhammer bug with only regular memory accesses. This allows to trigger the Rowhammer bug in highly restricted and even scripting environments. We demonstrate a fully automated attack that requires nothing but a website with JavaScript to trigger faults on remote hardware. Thereby we can gain unrestricted access to systems of website visitors. We show that the attack works on off-the-shelf systems. Existing countermeasures fail to protect against this new Rowhammer attack.
1 Introduction
The paper presents Rowhammer.js, which replaces cache flushing with fast eviction using regular memory accesses and enables remote JavaScript attacks that trigger Rowhammer faults.
- Motivation and approach: Fast cache eviction with regular memory accesses replaces the clflush instruction for triggering Rowhammer faults.The approach targets complex and undocumented cache replacement policies on recent Intel CPUs.
- Attack workflow: The attack uses two addresses in different DRAM rows, repeatedly evicts and reloads them, searches for a bit flip, and exploits it.The exploitation stage can target page tables or enable remote code execution.
- Attack workflow: Large arrays allocated on large pages help JavaScript determine parts of physical addresses without exploiting browser or JavaScript weaknesses.This addresses the challenge of locating suitable memory rows in a sandboxed environment.
- Countermeasures: Existing software countermeasures do not sufficiently protect against JavaScript attacks, while hardware changes are difficult to deploy on legacy and vulnerable DDR4 systems.BIOS updates can address the problem on commodity systems but are practical mainly for very advanced users.
- Contributions: The authors build native and pure JavaScript implementations that trigger Rowhammer bit flips using only memory accesses.The implementations target Sandy Bridge, Ivy Bridge, Haswell, and Skylake across DDR3 and DDR4 configurations.
- Contributions: Remote JavaScript can trigger Rowhammer bit flips through a web browser, potentially giving website attackers unrestricted access to visitor systems.The proof of concept runs in recent Firefox and Google Chrome versions.
2 Background
The background describes DRAM organization and Rowhammer's adjacent-row corruption, then explains how cache structure and eviction determine whether attacks can drive frequent DRAM accesses.
- DRAM: DRAM banks contain rows of capacitor cells whose charge represents binary data and must be periodically refreshed.DDR3 and DDR4 specifications require all rows to be refreshed at least once within 64ms.
- The Rowhammer bug: Rowhammer corrupts data in rows near frequently accessed rows because shrinking DRAM cells can electrically interact despite intended isolation.The bug affects cells that are not directly accessed.
- The Rowhammer bug: Most off-the-shelf DRAM modules were found vulnerable to bit flips using clflush, which forces subsequent accesses to DRAM.Prior exploits used repeated flushes and accesses to two locations to cause flips in a third.
- The Rowhammer bug: Native Rowhammer exploits used clflush for privilege escalation through page-table flips and sandbox escape through flips in indirect jumps.Removing clflush from allowed Native Client instructions was proposed as a countermeasure.
- CPU caches: CPU caches store copies of frequently used data, and their sets, slices, and replacement policies determine which lines are evicted.Intel cache replacement policies are undisclosed, while some architectures have been reverse-engineered.
- Cache attacks and eviction: Cache eviction is central to both cache attacks and Rowhammer, but high eviction rates with low execution time require nontrivial access-sequence design.Large-buffer eviction is too slow, while congruent-address mapping alone does not solve sequence construction.
3 Cache Eviction Strategies
The paper develops automated cache-eviction strategies that replace clflush by exploiting cache-set behavior and undocumented replacement policies. These strategies improve eviction performance and enable Rowhammer-relevant memory accesses, while evaluation shows bit-flip likelihood depends mainly on very high eviction rates and low execution time.
- Strategy model: Eviction strategies specify an eviction set and an access pattern, with the pattern determining address order and repeated accesses.The paper distinguishes static and dynamic eviction sets and access patterns, then searches for effective strategies offline and online.
- Strategy model: Only accesses to congruent addresses in the same cache set materially influence eviction, so effectiveness depends on the eviction-set size.Non-congruent accesses do not change eviction rates when timing remains comparable.
- Strategy model: Repeated accesses can improve eviction: on Haswell, duplicating accesses reduced execution time by more than 33% and significantly increased eviction rate when repeated.Replacement policies may prefer evicting recently added lines, making repeated accesses necessary to keep the eviction set in the cache.
- Evaluation: The number of bit flips cannot reliably evaluate a single eviction strategy because timing and access counts vary widely and prolonged testing can permanently damage DRAM cells.The authors instead use bit flips to study how execution time, cache behavior, and eviction rate influence flip probability.
- Evaluation: 81% of bit flips occurred at eviction rates of 99.75% or higher, while cache hits and misses did not significantly affect bit-flip counts.Bit flips also occurred at lower rates, but with significantly lower probability; high execution times were too slow and low times were ineffective without high eviction rates.
- Evaluation: The best two Haswell strategies, P-5-2-2-18 and P-2-2-1-17, achieved eviction rates above 99.75% with execution times around 180 nanoseconds.They were compared with clflush-based Rowhammer and the fastest LRU strategy.
4 Implementation of eviction-based Rowhammer
The authors evaluate eviction-based Rowhammer across native and JavaScript settings, replacing clflush with regular memory accesses. They reproduce bit flips on several systems and demonstrate a fully automated remote JavaScript attack.
- Evaluation scenarios: Eviction strategies replace clflush across native-code, known-address JavaScript, and fully remote JavaScript Rowhammer scenarios.The evaluation progresses from native execution to JavaScript with physical-address knowledge and finally to an attack requiring no additional system information.
- Native-code evaluation: Bit flips were reproducibly induced on Sandy Bridge, Ivy Bridge, and Skylake systems with Samsung DDR3 or Crucial DDR4 RAM in default configurations.The result was obtained using multiple eviction strategies rather than cache-flush instructions.
- Refresh-rate dependence: Haswell required increasing tREFI from 6,549 to over 19,000 before bit flips could be triggered even with clflush.The default configuration did not produce reproducible flips, and refresh-interval sensitivity also applies to eviction-based and JavaScript attacks.
- Hardware variability: 85% of examined DDR3 modules were previously found susceptible, while three of the authors’ five tested DIMMs were vulnerable at default settings.The Haswell and G.Skill Skylake modules were exceptions at default refresh settings.
- JavaScript attack: The JavaScript attack exploits 2MB page allocation to organize row offsets and perform double-sided or amplified single-sided hammering without outside computation.Large typed arrays provide 16 row offsets of 128KB within each 2MB region.
- JavaScript results: Bit-flip probability in JavaScript was slightly lower than in native code, but Ivy Bridge also produced flips from JavaScript with default settings.The comparison was measured using a fixed address pair known to be susceptible, across refresh-rate setups.
- DDR4 evaluation: Crucial DDR4 DIMMs produced bit flips at default settings with a recent BIOS, whereas G.Skill DDR4 required an increased refresh interval.The result was obtained after applying reverse-engineered physical-address functions.
5 Discussion and Related Work
The discussion examines exploitation, attack limitations, countermeasures, and related work. It shows that eviction-based Rowhammer can support privilege escalation while remaining constrained by memory layout, browser behavior, refresh settings, and incomplete defenses.
- Exploitation: Amplified single-sided hammering increases the probability of flips in surrounding rows and can cross physically coherent 2MB-region borders.The authors use this technique to support page-table manipulation after triggering a JavaScript bit flip.
- Exploitation: The proof-of-concept gains full physical-memory access on recent Linux systems with Firefox, but does not work in Google Chrome because 1MB arrays allocate all physical memory after one access.It also does not require a near-out-of-memory condition.
- Limitations: Without 2MB pages, double-sided and amplified single-sided hammering become unavailable or less effective, leaving only a limited set of adjacent rows for cross-region flips.Searching for an exploitable JavaScript bit flip can take several hours, and eviction-strategy precomputation can take up to an hour.
- Countermeasures: Shared libraries should not be shared across different privilege levels or users, because hammering shared code or data can induce faults usable for sandbox escape.This recommendation addresses both clflush-based and eviction-based Rowhammer.
- Countermeasures: Increasing refresh rates can significantly reduce performance, while supplied BIOS updates that merely double refresh rates remain insufficient for all DRAM modules.Many users also do not update BIOS unless doing so is unavoidable.
- Countermeasures: TRR was removed from the final DDR4 standard, and its device-level implementation has no effect when unsupported by the memory controller.pTRR and TRR refresh neighboring rows after access thresholds are exceeded.
- Countermeasures: ECC memory cannot reliably protect against Rowhammer attacks.The paper cites recent work supporting this limitation.
- Countermeasures: Hardware-performance-counter detection can identify excessive cache references and hits but may produce false positives requiring further evaluation.The paper presents this as a proposed software-level countermeasure rather than a settled defense.
6 Future Work
The authors identify extensions beyond their Linux browser study. The same allocation principles could apply to hypervisors using 4KB pages, including public-cloud settings where page deduplication remains common.
- Future applications: The attack was investigated only in Firefox and Google Chrome on Linux, but relies on hardware and operating-system concepts rather than browser-specific behavior.The authors connect the approach to systems using 4KB pages and page tables.
- Future applications: Hypervisors allocating 4KB pages to virtual machines could face a similar attack, including environments where cross-VM page deduplication is widely used.The paper identifies public clouds as a relevant setting for this extension.
7 Conclusion
Rowhammer.js uses fast cache eviction and regular memory accesses to enable automated remote attacks through JavaScript. The threat is substantial because most DDR3 modules and some DDR4 modules are vulnerable, while website-based attacks can target millions of machines simultaneously.
- Rowhammer.js uses fast cache eviction with regular memory accesses and operates independently of CPU microarchitecture, programming language, and execution environment.The authors also report benefits for cache-attack research on recent and unknown CPUs.
- A fully automated JavaScript attack delivered through a remote website can gain unrestricted access to systems.The attack is described as independent of the CPU instruction set and demonstrated in recent Firefox and Google Chrome versions.
- Most DDR3 modules are vulnerable, DDR4 modules can also be vulnerable, and automated website attacks can target millions of victim machines simultaneously.