Posthammer – Computer Security Group

Posthammer shows that browser-based Rowhammer attacks are pervasive. This means that if you use DDR4 memory technology, a mere visit to a malicious website is sufficient for the attacker to obtain a so-called arbitrary read-write primitive in your browser.

The attacker’s challenge

To obtain his primitive, the attacker needs to bypass the memory module’s Rowhammer mitigation. Previous work has shown this to be possible (see Blacksmith), but only natively and by building rather complex patterns that extensively use cache flushing instructions. It was unclear whether and how such patterns would translate to the browser.

The difficulty lies in the fact that the browser-based attacker is rather limited: the workspace is not any C program, as it was for Blacksmith, but client-side JavaScript, which not only lacks cache flushing instructions but generally obscures a lot of low-level system information the attacker needs.

Posthammer’s solution: refresh postponement and lanes

Posthammer shows how (i) refresh postponement and (ii) lanes enable the attacker to overcome this challenge. First, refresh postponement: we have shown that a long and dense series of memory accesses causes the memory controller to postpone refresh commands. This had not been shown before. But more importantly, we also found that postponing benefits the attacker: Rowhammer access patterns that postpone refresh commands are generally stronger. This makes it easier to trigger bit flips from within the JavaScript sandbox.

Another essential ingredient of our solution is lanes. Blacksmith shows that the majority of effective patterns are non-uniform. In a non-uniform pattern, not all aggressors are hammered evenly. Natively, constructing non-uniform patterns is as hard as constructing uniform patterns, but the same does not apply to the browser. Because the attacker cannot use cache flushing instructions, he uses eviction sets instead, and eviction sets make it nontrivial to build non-uniform access patterns. Posthammer, however, solves this problem with lanes: a new abstraction that divides the pattern into minimal eviction sets. These minimal eviction sets, now lanes, are woven together for fine-grained non-uniformity despite the lack of cache flushing instructions.

By combining refresh postponement with lanes, we were able to compromise 61% (17/28) of the DDR4 devices in our testbed (JavaScript) and trigger bit flips without flushing (natively) on 86% (24/28) of them.

Should I worry?

There are easier ways to compromise the browser than Posthammer, so an average user does not need to worry about this attack. Furthermore, while Posthammer escapes the JavaScript sandbox—a first and significant layer of browser security—more work is needed to turn it into a full-fletched attack. That said, Posthammer shows that solving Rowhammer continues to be important.

Paper and source code

Posthammer will be presented at USENIX Security ’25. The paper can be found here. All of Posthammer’s source code can be found on GitHub.

Posthammer has received all three artifact badges: available, functional, and reproduced, which means independent and anonymous artifact evaluators have been able to reproduce our results.