SledgeHammer: Amplifying Rowhammer via Bank-level Parallelism

Rowhammer is a hardware vulnerability in DDR memory by which attackers can perform specific access patterns in their own memory to flip bits in adjacent, uncontrolled rows without accessing them. Since its discovery by Kim et. al. (ISCA 2014), Rowhammer attacks have emerged as an alarming threat to numerous security mechanisms. In this paper, we show that Rowhammer attacks can in fact be more effective when combined with bank-level parallelism, a technique in which the attacker hammers multiple memory banks simultaneously. This allows us to increase the amount of Rowhammer-induced flips 7-fold and significantly speed up prior Rowhammer attacks relying on native code execution. Furthermore, we tackle the task of mounting browser-based Rowhammer attacks. Here, we develop a self-evicting version of multi-bank hammering, allowing us to replace clflush instructions with cache evictions. We then develop a novel method for detecting contiguous physical addresses using memory access timings, thereby obviating the need for transparent huge pages. Finally, by combining both techniques, we are the first, to our knowledge, to obtain Rowhammer bit flips on DDR4 memory from the Chrome and Firefox browsers running on default Linux configurations, without enabling transparent huge pages. ing Rowhammer attacks on DDR4, causing up to seven-fold increase in the amount of flips compared to other hammering techniques. Moreover, using multi-bank hammering we are able to demonstrate the first Rowhammer bit flips on Intel's 12th generation (Alder Lake) architecture. Finally, we show that multi-bank hammering can be performed in browser contexts, demonstrating the first Rowhammer attack in both Chrome and Firefox under default configurations, without Transparent Huge Pages (THPs). Multi-Bank Hammering. The main observation behind multi-bank Rowhammer is that while memory accesses are often written sequentially, they are actually performed in parallel when accessing different memory banks. Thus, by accessing many banks simultaneously we are essentially able to parallelize Rowhammer, improving prior works by obtaining about a 7-fold increase in the amount of bitflips found within an hour of hammering in native-code environments. Avoiding clflush. Going beyond native contexts, we next consider browser-based Rowhammer attacks. To that aim, we must avoid any use of the clflush instruction, replacing it with cache eviction techniques. Here, we introduce a new hammering technique dubbed "SledgeHammer", that leverages multi-bank hammering to improve the result of [8], traversing a set of addresses that both hammers and fully self-evicts without the use of any dummy elements. This in turn allows us to create a self-evicting Rowhammer attack without using clflush, which is required for browser-based hammering. Avoiding Transparent Huge Pages (THPs). The next step for enabling browser-based Rowhammer attacks is the need to obtain 2 MB blocks of physically contiguous memory. Not wanting to assume a non-default configuration of transparent huge pages being enabled in the kernel, we develop a novel approach for detecting physically contiguous pages using memory access timing from within the browser. This allows us to obtain the first browser-based Rowhammer attack on DDR4 memory using a fully default configuration, taking 20 seconds on average to obtain the first bit flip. Improving End-to-End Rowhammer Attacks. As a final contribution, we show how our techniques can be used to significantly improve the performance of Rowhammer. First, in the native setting we demonstrate an opcode flipping attack against the sudo binary, allowing unprivileged code to obtain root permissions within minutes. We then extend the RAMBleed [41] attack to DDR4 memory, showing a leakage rate of 1.369 bits / second. Finally, we tackle browser-based Rowhammer, obtaining flips up to 169 bits / hour, as well as demonstrating a 64-bit write primitive on Firefox. Summary of Contributions. We contribute the following: • We use bank-level parallelism to construct multi-bank hammering, and show that it can flip bits that were hitherto unflippable using prior techniques (Section 4). • We analyze the root cause behind multi-bank hammering across different Intel architectures (Section 5).