Skip to content

Rowhammer.js - Memory Corruption via JavaScript

Posted on:July 31, 2015 at 03:00 AM

Recently I stumbled into an interesting paper. This paper introduces a bug / vulnerability called “Rowhammer.js”. In short: Rowhammer.js enables hardware-level memory corruption (bit flips) via web browser. Yes, it sounds insane, it is insane, and yet it seems to be a real thing. I believe this may become a major client-side web security issue.

Rowhammer and Rowhammer.js

Rowhammer itself is one awesome bug. The vulnerability is not in software, driver or firmware, but hardware (DRAM devices, to be more precise). It can be exploited by repeatedly accessing a certain memory row using certain CPU instructions, and eventually a bit on that row may be accidentally flipped (even though that specific bit it is never written or read). This sounds weird but rather harmless. However, it is not harmless. This practically could allow attacker to modify write-protected data and gain kernel privileges.

Example by Google’s Project Zero:

Rowhammer.js takes exploiting this vulnerability to the next level: via web browser using JavaScript code. Proof-of-concept exploits by Google require low-level commands and native executables. Thus, at first glance this vulnerability seems impossible to exploit using high-level scripting languages. However, there are always some tricks you can do.

Paper by Daniel Gruss, Clémentine Maurice and Stefan Mangard comprehensively describes the issue and provides the idea on how this vulnerability can be exploited via JavaScript in web browser. The paper is available at


In worst scenario, this kind of vulnerability could allow any website to compromise all JavaScript-enabled clients and get unrestricted access to their files (in ideal situation). Of course, there is a long way from a research paper to reliable exploit. But as I said, this may become a major web security issue. However, I express the word “may”. According to what I have read and seen, it is still a bit unclear for me, how practical this vulnerability is a) to exploit, and b) to patch.

Of course, there have been a lots of zero-day RCEs in past, such as recent Flash zerodays, let alone all those Java vulnerabilities. However, I would consider a purely JavaScript-based RCE or privilege elevation even more critical. Currently, many people are aware of weaknesses in Flash and Java. Not everyone have Flash and Java plugins enabled by default . In today’s Internet, is much more difficult to make people disable JavaScript.