Read the original article here.

---

The Forbidden Code: Exploiting the Physical Substrate - A Deep Dive into Rowhammer

Welcome, fellow explorers of the digital underground. In the conventional world of programming, we learn about clean abstractions, secure coding practices, and relying on the operating system's guardians like memory protection. But beneath these layers of software lies the physical reality of hardware, where unintended side effects can become powerful, forbidden tools.

Today, we're peeling back those layers to examine a vulnerability known as Rowhammer. It's not a bug in your code, nor a flaw in the operating system's logic. It's a physical phenomenon occurring within the very memory chips your programs run on, capable of bypassing fundamental security mechanisms. Understanding Rowhammer is understanding how the physical world can betray digital security, and how "forbidden" knowledge of hardware quirks can open doors thought to be locked.

What is Rowhammer?

At its core, Rowhammer is an exploit that leverages an undesirable physical interaction within Dynamic Random-Access Memory (DRAM) chips. By repeatedly accessing (or "hammering") certain memory rows, you can induce electrical interference that affects data stored in adjacent rows, potentially causing bit flips – changing a '1' to a '0' or vice versa – without ever directly writing to those adjacent rows.

Rowhammer: An unintended side effect in high-density DRAM where repeatedly accessing specific memory rows can electrically interfere with and alter the data stored in nearby, non-accessed rows, potentially causing bit flips.

This circumvention of the isolation between memory cells arises from the extreme density of modern DRAM chips. It's a physical leakage of charge, triggered by specific, rapid memory access patterns.

The Foundation: Understanding DRAM's Physical Reality

Before we dive into the attack, it's crucial to understand the basics of how DRAM works at a physical level. This isn't the clean, abstract byte array you see in high-level languages; it's a grid of tiny electrical components.

Dynamic Random-Access Memory (DRAM): A type of volatile memory used for main system memory (RAM) that stores each bit of data in a separate capacitor within an integrated circuit. It is called "dynamic" because it requires periodic refreshing to maintain the data charge.

Each bit in DRAM is stored in a memory cell, implemented with one capacitor and one transistor. The state of the capacitor (charged or discharged) represents a '1' or '0'.

Memory Cell: The fundamental unit of storage in DRAM, consisting of a capacitor to hold a charge (representing a bit) and a transistor acting as a switch to access the capacitor.

These millions or billions of cells are organized into a matrix structure. Data is addressed using row and column addresses. When you want to read or write data, the memory controller first uses the row address to select an entire row of cells. This selection is known as row activation.

Row Activation: The process of selecting a specific row in the DRAM matrix to access its data. This involves applying voltage to the row's word line, enabling access to the capacitors in that row.

When a row is activated, the charge from all capacitors in that row is transferred into sense amplifiers, which collectively form the row buffer. The data from the desired column is then selected from this buffer. Because this process discharges the original capacitors, reading in DRAM is destructive. The data must be written back from the sense amplifiers to restore the row's state after a read operation. Similarly, a write operation requires activating the row, modifying the sense amplifier data for the target bit, and then writing the entire row back.

Sense Amplifiers (Row Buffer): Electronic circuits in DRAM that detect and amplify the weak charge signals from memory cells during a read operation. They temporarily hold the data for the entire activated row before it is sent to the memory controller and written back to the DRAM cells.

Capacitors naturally lose their charge over time. To prevent data loss, DRAM requires periodic refreshing. The memory controller cycles through all rows, activating each one to replenish the charge in its capacitors.

Refresh: The process of periodically reading and rewriting data in DRAM cells to restore their charge and prevent data loss due to capacitor discharge. This happens automatically at regular intervals (typically every 64 milliseconds for standard DRAM).

DRAM is also susceptible to soft errors, random bit flips caused by external factors like cosmic rays or alpha particles. Error-Correcting Code (ECC) memory is a common technique to detect and sometimes correct these errors.

Soft Error: An error in data where the stored value changes (a bit flips) due to external factors (like radiation) but the underlying memory hardware itself is not permanently damaged.

While ECC and refreshing counteract natural discharge and random soft errors, they weren't designed to handle the specific stress pattern of Rowhammer.

The Vulnerability: Why Hammering Works

The key to Rowhammer lies in the relentless pursuit of density in modern DRAM. As manufacturers pack more and more cells onto a chip, the cells become physically smaller and closer together.

• Smaller Cells: Less physical space means smaller capacitors, holding less electrical charge.
• Higher Density: Cells are closer, increasing the potential for electrical interference between them.
• Lower Noise Margins: With less charge and more interaction, the threshold for a state change due to interference is lower.

This combination makes modern DRAM susceptible to disturbance errors – errors caused by the electrical activity of one cell interfering with others.

Disturbance Errors: Bit flips occurring in a memory cell not due to natural discharge or external radiation, but due to the electrical activity (specifically, repeated activation) of nearby memory cells.

Researchers demonstrated in 2014 that commercially available DDR3 chips were prone to these errors when subjected to rapid row activations. The voltage fluctuations on the activation lines of frequently accessed rows ("aggressor rows") induce higher-than-normal discharge rates in the capacitors of adjacent rows ("victim rows"). If a victim row isn't refreshed quickly enough after being affected by hammering, its bit states can flip.

Tests showed that hammering a row around 139,000 times consecutively (while ensuring memory accesses weren't served from CPU cache) could cause bit flips in nearby rows. Some vulnerable chips saw flips after even fewer accesses. Disturbingly, up to 1 in every 1,700 cells tested were found to be susceptible. The rate of errors can also depend on the pattern of bits stored in memory, as certain patterns might amplify the electrical interference.

Attack Mechanics: Crafting the Hammer

The basic Rowhammer attack involves repeatedly activating an "aggressor" row. To ensure these activations hit the DRAM chip directly and aren't serviced by the CPU's cache (which would defeat the purpose of physically hammering the DRAM), the attacker must employ techniques to bypass or evict data from the cache. This is often done using instructions like clflush (on x86) or by accessing large amounts of data designed to overwhelm the cache capacity, forcing evictions.

Cache Flushing/Eviction: Techniques used by an attacker to ensure memory accesses go directly to DRAM rather than being served from the CPU's high-speed cache. This is necessary to trigger the physical Rowhammer effect.

Over time, as DRAM manufacturers introduced mitigations, attackers developed more sophisticated hammering patterns:

1. Basic Single-Sided Hammering: Repeatedly activating one aggressor row adjacent to a victim row (e.g., Row A, Row A, Row A...).
2. Double-Sided Hammering: Activating two rows adjacent to the victim row alternately (e.g., Row A, Row B, Row A, Row B...), where the victim row is between A and B. Tests showed this can significantly increase the rate of bit flips.
3. Non-Uniform/Frequency-Based Patterns: More advanced patterns that involve hammering multiple aggressor pairs with varying frequencies, phases, and amplitudes. These are designed to find "blind spots" or weaknesses in specific mitigation implementations. Tools like the Blacksmith fuzzer are used to discover these patterns.
4. Many-Sided Hammering: An evolution, particularly effective against DDR4 mitigations (like TRRespass), which hammers multiple rows around a victim row, often using specific patterns found through fuzzing.

The goal of all these patterns is the same: induce enough electrical stress on the victim row's capacitors within the refresh interval to cause a state change before the regular refresh cycle can restore the correct data.

Why It's Dangerous: Implications for System Security

This low-level hardware phenomenon has profound implications for higher-level software security. Most modern operating systems rely heavily on memory protection and privilege separation to isolate processes from each other and the operating system kernel.

Memory Protection: A mechanism provided by the operating system and hardware (like the Memory Management Unit - MMU) to control access rights to memory, preventing one process from reading or writing memory allocated to another process or the kernel.

Privilege Separation: The principle of designing systems such that different parts have only the minimum privileges necessary to perform their function. This limits the damage a vulnerability in one part can cause to the rest of the system.

These security layers assume that memory contents only change through legitimate read/write operations initiated by code running with the appropriate permissions.

Rowhammer shatters this assumption. It's a hardware-level bypass. By manipulating the physical state of DRAM cells directly through electrical interference, an attacker can alter memory contents without going through the standard memory access pathways governed by the operating system's memory protection. It's like picking the lock on a vault not by finding a software bug in the access control system, but by vibrating the wall next to the lock until a bolt slips.

This creates a completely new attack vector, allowing a malicious process with low privileges to potentially modify critical data belonging to other processes or even the operating system kernel, bypassing all traditional software-based defenses like firewalls, antivirus, and secure coding practices.

The Exploits: From Bit Flips to Full Control

The potential for exploiting Rowhammer became chillingly clear in 2015 when Google's Project Zero demonstrated working privilege escalation exploits.

The initial 2014 research only showed that bit flips could occur in real-world DDR3 chips and hinted at attack possibilities. The October 2014 follow-up didn't focus on security implications.

But Project Zero's March 2015 reveal changed everything. They showed two concrete exploits on x86-64 Linux:

1. Sandbox Escape (Google Native Client - NaCl): NaCl is a technology designed to run untrusted code (like plugins) in a highly restricted sandbox environment within the browser, preventing it from accessing the rest of the system. One exploit used Rowhammer within the NaCl sandbox. By hammering memory, it caused bit flips in data structures outside the sandbox. Specifically, it targeted data that, when flipped, allowed the sandboxed code to gain the ability to make system calls directly, effectively escaping the sandbox (CVE-2015-0565). This initial exploit relied on the clflush instruction to ensure cache misses, and NaCl was modified to disallow this instruction to mitigate it.

2. Linux Privilege Escalation: This even more concerning exploit ran as an unprivileged user-level process on Linux. It used Rowhammer to flip bits in page table entries.

   Page Tables: Data structures used by the operating system's virtual memory system to translate virtual memory addresses (what programs see) into physical memory addresses (where data is actually stored in RAM). The MMU uses these tables for access control and translation.

   Page table entries contain not just the physical address mapping, but also permission bits (read, write, execute, user/kernel). By carefully timing Rowhammer attacks and using techniques like memory spraying (allocating and placing specific data patterns in memory locations likely to be near target page tables), the exploit could flip a permission bit in a page table entry.

   Memory Spraying: A technique used in some exploits where large amounts of memory are allocated and filled with specific data patterns in an attempt to place malicious data or target data structures (like page tables) in predictable or exploitable locations within memory.

   A common target for flipping is the user/supervisor bit or a write permission bit. Flipping one of these could give the unprivileged process write access to kernel-owned memory regions (where the kernel's page tables reside, or even the kernel code itself). Once an attacker can write arbitrary data to kernel memory, they can typically gain full root privileges.

   This Linux exploit was particularly dangerous because it did not strictly require the clflush instruction; it could achieve cache misses through other means. This made it difficult to mitigate purely in software on vulnerable hardware. Project Zero found that roughly half of the laptops they tested (manufactured 2010-2014) were susceptible, sometimes experiencing flips within minutes.

In July 2015, researchers upped the ante with an architecture- and instruction-set-independent Rowhammer exploit. Instead of relying on specific instructions like clflush, they developed an adaptive cache eviction strategy that could force cache misses by simply accessing large, carefully chosen memory patterns that overwhelm the cache's capacity, regardless of the CPU architecture or its specific cache replacement policy.

The most striking demonstration of this was Rowhammer.js, a pure JavaScript implementation running in Firefox. It used large typed arrays (a JavaScript feature) which are internally allocated using large pages. By strategically accessing these large arrays, the JavaScript code could induce the necessary cache eviction patterns and trigger Rowhammer bit flips. This showed that a low-level hardware vulnerability could be exploited from a high-level scripting language running inside a browser sandbox!

The threat continued to evolve:

• DRAMMER (2016): Demonstrated Rowhammer on Android devices, achieving root access on several popular smartphones. This showed Rowhammer wasn't confined to desktops/servers. Mitigations like isolating DMA buffers with "guard rows" were proposed to counter Rowhammer attacks delivered via Direct Memory Access (DMA).
• TRRespass (2020): Showed that built-in Rowhammer mitigations on DDR4 chips, previously thought to be resistant, could be bypassed using new attack patterns like many-sided hammering.
• Half-Double (2021): A Google exploit targeting even newer DRAM chips, exploiting worsening physics where activating one row could affect not just adjacent rows, but rows two distance away.
• ZenHammer (2024): The first Rowhammer exploit demonstrated on AMD Zen architecture CPUs and, significantly, the first confirmed Rowhammer exploit on DDR5 SDRAM, proving the issue persists in the latest memory technology.
• RISC-H (2024): The first Rowhammer study and exploit targeting RISC-V architecture, showing the vulnerability is not tied to x86 or ARM.

These continuous developments highlight that Rowhammer is not a solved problem; it's an ongoing arms race between attackers finding new patterns and manufacturers implementing new mitigations.

Defending Against the Hammer: Mitigation Techniques

Given the physical nature of the vulnerability, preventing Rowhammer requires hardware-based solutions or software workarounds at a very low level. Traditional software defenses are largely ineffective.

• Basic ECC Memory: Standard Error-Correcting Code (like SECDED, which corrects single-bit errors and detects double-bit errors) is often insufficient. Rowhammer can cause multiple bit flips (more than two) within a single memory word, which SECDED cannot correct and may not even detect. Research has also shown targeted three-bit flips can specifically defeat SECDED's detection.
• Increased Refresh Frequency: One simple mitigation is to increase how often the DRAM is refreshed (shorter than the standard 64ms interval). More frequent refreshes mean victim rows have less time to lose charge due to hammering before being restored. However, this impacts performance (memory is unavailable during refresh) and increases power consumption. Some vendors released firmware updates implementing this.
• Proactive/Adaptive Refresh: More sophisticated hardware or firmware solutions track memory access patterns.
  • Counter-Based Refresh: Identify frequently activated ("hot") rows by counting accesses. Proactively refresh the neighboring rows of these hot rows before they are likely to flip.
  • Random Refresh: Issue additional, infrequent refreshes of random rows neighboring recently accessed rows, regardless of activation count. These methods have negligible performance impact compared to simply increasing the global refresh rate.
• Target Row Refresh (TRR): A hardware mitigation included as an option in the LPDDR4 mobile standard and implemented by some manufacturers in DDR4 (though not part of the standard). TRR attempts to identify potential victim rows by monitoring access counts to nearby rows using chip-specific thresholds:

  Maximum Activate Count (MAC): The maximum number of times a row pair can be activated within a specific time window before triggering a mitigation action (like refreshing neighboring rows). Maximum Activate Window (t_MAW): The time interval over which row activations are counted for the MAC threshold. If activations of aggressor rows exceed MAC within t_MAW, TRR refreshes the identified victim rows. While designed to be performant, research (like TRRespass) has shown that attackers can find access patterns that bypass TRR implementations on real chips.

• Pseudo Target Row Refresh (pTRR): Supported by some Intel Xeon processors since Ivy Bridge when paired with pTRR-compliant DDR3 DIMMs. Similar to TRR, it automatically refreshes potential victim rows. If used with non-pTRR DIMMs, these processors may fall back to doubling the refresh frequency, causing slight performance penalties.
• Detection via Performance Counters: Rowhammer exploits require a high rate of uncached memory accesses, leading to many cache misses. Monitoring hardware performance counters for unusual peaks in cache miss rates can potentially detect Rowhammer activity, although this is a detection rather than prevention mechanism.
• MemTest86: The memory diagnostic tool includes a specific test (available in UEFI boot mode) to check if a system's RAM is susceptible to Rowhammer disturbance errors.

The constant discovery of new bypass techniques (Blacksmith, many-sided hammering) demonstrates that hardware mitigations need to be robust and possibly adaptive to unknown future attack patterns. Software-only patches are generally insufficient because they cannot prevent the underlying physical interaction, they can only try to detect specific, known attack patterns or restrict behaviors thought to be necessary for the attack (like clflush), which attackers may then circumvent.

The Ever-Evolving Threat

Rowhammer is a prime example of how hardware limitations and physical effects can become security vulnerabilities. It highlights the breakdown of software abstractions when faced with the messy reality of the physical world.

As DRAM densities increase, the fundamental physics that enable Rowhammer are likely to persist or even worsen (as suggested by Half-Double). While manufacturers implement mitigations, attackers are constantly finding new, more complex patterns to bypass them, as seen with TRRespass, ZenHammer, and RISC-H targeting newer generations and architectures.

This makes Rowhammer an enduring topic in low-level security research and a potent reminder that true system security requires understanding and addressing vulnerabilities across the entire stack, from the silicon up through the operating system and applications. For those delving into the "forbidden code," Rowhammer serves as a fascinating case study in exploiting the unintended consequences of physical design.

---