PaperlayerView exact revision on arXiv

Source-linked AI summary

Nethammer: Inducing Rowhammer Faults through Network Requests

Moritz Lipp, Misiker Tadesse Aga, Michael Schwarz, Daniel Gruss, Clémentine Maurice, Lukas Raab, Lukas Lamster

arXiv:1805.04956v1cs.CR

TL;DR

The paper addresses whether Rowhammer can induce and exploit bit flips without local code execution. It presents Nethammer, which uses crafted network traffic to trigger the memory accesses needed for remote hammering, and demonstrates bit flips and security or availability impacts across multiple systems. The findings require re-evaluating defenses and threat models for network-connected devices, although the attack depends on high traffic and can be difficult to detect or counter with existing mechanisms.

  • Problem

    Prior Rowhammer attacks required local code execution, leaving it unclear whether attackers could induce and exploit bit flips remotely.

  • Method

    Nethammer sends crafted high-rate network packets whose processing repeatedly accesses memory, exploiting uncached memory, flush instructions, or Intel CAT to induce DRAM activity without attacker-controlled victim code.

  • Results

    Nethammer induced multiple bit flips per hour on real-world systems using uncached memory, flush instructions, or Intel CAT, causing temporary or persistent system damage.

  • Takeaways & Limitations

    Remote Rowhammer requires re-evaluating the security of network-connected systems and developing countermeasures that address both local and remote attacks.

  • Takeaways & Limitations

    The attack requires extraordinary network traffic, and network monitoring may detect and stop it.

Abstract

from arXiv · show

A fundamental assumption in software security is that memory contents do not change unless there is a legitimate deliberate modification. Classical fault attacks show that this assumption does not hold if the attacker has physical access. Rowhammer attacks showed that local code execution is already sufficient to break this assumption. Rowhammer exploits parasitic effects in DRAM to modify the content of a memory cell without accessing it. Instead, other memory locations are accessed at a high frequency. All Rowhammer attacks so far were local attacks, running either in a scripted language or native code. In this paper, we present Nethammer. Nethammer is the first truly remote Rowhammer attack, without a single attacker-controlled line of code on the targeted system. Systems that use uncached memory or flush instructions while handling network requests, e.g., for interaction with the network device, can be attacked using Nethammer. Other systems can still be attacked if they are protected with quality-of-service techniques like Intel CAT. We demonstrate that the frequency of the cache misses is in all three cases high enough to induce bit flips. We evaluated different bit flip scenarios. Depending on the location, the bit flip compromises either the security and integrity of the system and the data of its users, or it can leave persistent damage on the system, i.e., persistent denial of service. We investigated Nethammer on personal computers, servers, and mobile phones. Nethammer is a security landslide, making the formerly local attack a remote attack.

1 INTRODUCTION

Nethammer challenges the accepted assumption that Rowhammer requires local code execution by inducing exploitable bit flips through network traffic alone. The paper develops the attack, evaluates its effects, and argues that remote Rowhammer changes the threat model for network-connected systems.

  • Previously known Rowhammer attacks required local code execution, so systems without attacker-controlled code were considered safe.
  • Nethammer is the first Rowhammer attack requiring no attacker-controlled code on the victim and only a fast network connection.
  • Crafted packets repeatedly access the same memory locations, while uncached memory, flush instructions, or Intel CAT can produce frequent DRAM accesses and induce bit flips.
  • The paper systematically studies memory-controller policies, one-location hammering, and network-packet memory operations as building blocks for Nethammer.
  • Bit flips were observed after 300 ms and at rates up to 10 000 per hour, enabling service compromise or persistent denial of service.
  • The authors report that many existing defenses, including TRR, do not work against Nethammer and that the attack is difficult to detect amid high network traffic.

2 BACKGROUND

The background explains how DRAM organization, memory-controller policies, caches, and Rowhammer interact. It also introduces hammering strategies, cache allocation, and prior Rowhammer exploits and defenses.

  • DRAM Organization: DRAM stores data in capacitor-based cells organized into rows and columns within banks, ranks, DIMMs, and channels.
  • Memory Controller Policies: Memory controllers use row buffers and page policies that determine whether accesses are row hits, precharged accesses, or row conflicts with different latencies.
  • Rowhammer: Rowhammer induces DRAM bit flips by repeatedly accessing adjacent rows at high frequency while bypassing caches through instructions, eviction, or uncached memory.
  • Hammering Strategies: Single-sided, double-sided, and one-location hammering differ in which rows are accessed and where bit flips are most likely to occur.
  • Rowhammer Impact and Defenses: Prior Rowhammer work demonstrated attacks including privilege escalation, sandbox escapes, cryptographic compromise, and cloud virtual-machine attacks, motivating defenses such as detection, neutralization, TRR, and MAC.
  • Caches and Cache Eviction: Intel CAT partitions last-level-cache ways among applications or virtual machines to improve isolation and quality of service, but restricted cache capacity increases eviction probability.

3 NETHAMMER ATTACK

Nethammer sends high-rate crafted network packets that cause packet-processing code to repeatedly access target memory locations, enabling remote Rowhammer without attacker-controlled victim code. The attack applies to systems using uncached memory, flush instructions, or Intel CAT, under stated hardware and connectivity assumptions.

  • Attack Design: Nethammer replaces local attacker-controlled execution with a crafted packet stream that repeatedly accesses addresses in kernel drivers or packet-processing applications.
  • Assumptions: The setup assumes a fast network connection and victim memory susceptible to one-location or single-sided hammering.
  • Attack Scenarios: Personal-computer attacks require no further assumptions, while cloud attacks assume a network-accessible virtual machine constrained by Intel CAT.
  • Attack Scenarios: The personal-computer and cloud attack setups overlap, so either class of system may also be vulnerable to the other scenario.
  • Attack Design: Uncached memory, clflush, or Intel CAT can make packet processing evict and reload data frequently enough to hammer corresponding addresses.
  • Traffic Generation: At 500 Mbit/s, minimum-size UDP packets can reach up to 1 024 000 packets per second, providing the high access rate needed for remote hammering.

4 FROM REGULAR MEMORY ACCESSES TO ROWHAMMER

This section develops Nethammer from ordinary network-driven memory accesses by classifying memory-controller policies, establishing one-location hammering on ARM, and showing that packet processing can reach a sufficient access frequency. These measurements support the feasibility of inducing Rowhammer bit flips through network traffic.

  • 4.1 Automated Classification of Memory-Controller Page Policies: The authors classify memory-controller page policies by comparing repeated accesses to one row with accesses causing a row conflict.They use addresses in the same bank but different rows, with cache flushing to measure main-memory behavior.
  • 4.1 Automated Classification of Memory-Controller Page Policies: For an open-page policy, repeated accesses retain the same timing, whereas adaptive policies change timing after sufficiently many accesses.The open-page system keeps the row open; the adaptive system leaves it open longer after larger access sequences.
  • 4.1 Automated Classification of Memory-Controller Page Policies: The classification distinguishes closed-page behavior from open and adaptive policies on an Intel Xeon D-1541, with results verified through the memory-controller configuration register.Closed-page behavior produces no timing difference between the repeated-access and conflict cases.
  • 4.1 Automated Classification of Memory-Controller Page Policies: Adaptive page policies often behave like closed-page policies, indicating that one-location hammering may work on systems using adaptive policies.This extends the relevance of one-location hammering beyond systems with explicitly closed-page policies.
  • 4.2 One-location Hammering on ARM: On an ARM-based Nexus 4, hammering one uncached address produced 4 bit flips during 10 hours, demonstrating vulnerability to one-location hammering.The device used LPDDR2 memory and a configurable closed-page policy.
  • 4.3 Minimal Access Frequency for Rowhammer Attacks: At 500 Mbit/s, packet processing can induce 6 144 000 memory accesses per second, or 393 216 accesses per 64 ms refresh interval.The estimate assumes 1 024 000 minimum-size packets per second and functions called six times per packet.

5 EXPLOITING BIT FLIPS OVER A NETWORK

This section examines how remotely induced bit flips can affect kernel, user, filesystem, DNS, certificate, and application data. Depending on the target location, Nethammer can cause crashes, persistent data loss, service disruption, redirection, or renewed trust in revoked certificates.

  • 5.1 Possible Locations of Bit Flips: Nethammer’s bit flips can affect user-accessible or kernel memory, but the attacker cannot control the physical location of the flip.The resulting consequences therefore depend on which data or code occupies the modified location.
  • 5.2 Bit Flip Targets: A bit flip in a filesystem inode can corrupt filesystem metadata, causing persistent data loss and potentially crashing the system.Inodes contain file ownership, permissions, size, and disk-block location information.
  • 5.2 Bit Flip Targets: A bit flip in user-space code or data can crash a program, make a service unavailable, or cause it to deliver modified content.Users may be unable to distinguish altered application data from correct data.
  • 5.2.1 DNS Entries: A DNS-entry bit flip can redirect users to attacker-controlled domains or mail servers by changing domain or MX records.The paper gives the example of changing domain.com to dnmain.com by flipping one character bit.
  • 5.2.3 Application Memory in General: An OCSP status bit flip can change a revoked certificate’s status from “R” to “V”; with 0.125 % probability per bit flip, the certificate may become usable again.The attacker could then use the known private key to sign documents or data while impersonating the original signer.
  • 5.2 Bit Flip Targets: The attack scenarios include distributing malicious software through compromised version-control hosting services and altering cryptographic material.The paper presents these as additional consequences of remotely modifying application memory.

6 EVALUATION

The evaluation tests Nethammer across cache-bypass mechanisms, memory-controller policies, and target systems. It induces bit flips in multiple settings, including systems with Intel CAT, and some flips corrupt kernels, halt systems, crash services, or remain exploitable despite TRR.

  • Evaluation setup: Nethammer was evaluated using clflush, Intel CAT-based eviction, and uncached memory across personal computers, servers, and an ARM-based mobile device.The test systems included a non-default flushing driver, Xeon systems configured with Intel CAT, and an ARM device using uncached memory.
  • Driver with clflush: 500 Mbit/s UDP traffic induced one bit flip every 350 ms with a network driver that flushed packet-handling addresses.This experiment used an Intel i7-6700K and required at least two memory accesses to be served from main memory.
  • Eviction with Intel CAT: 45 bit flips per hour were observed on an Intel Xeon E5-1630v4 using Intel CAT, despite active TRR.The authors report fewer flips than on systems without TRR.
  • Memory-controller page policies: 11 bit flips occurred in 4 hours with the Closed policy, while Open produced none in 4 hours but 46 in 10 hours, and Adaptive produced 10 in 4 hours.With Closed policy and 35% CPU load, 27 bit flips occurred within 15 minutes.
  • Bit-flip effects: Nethammer bit flips caused kernel-image corruption, system halts, process and service crashes, login failure, and other persistent or operational failures.The experiments also found that increasing a user program’s memory usage increased the chance of flipping a target page.
  • Target Row Refresh: TRR prevented flips in directly adjacent rows on one system but did not prevent exploitable flips, making the hardware countermeasure insufficient against Rowhammer.The comparison used the same pTRR-supporting DDR4 module on an Intel i7-6700K and an Intel Xeon E5-1630v4.

7 COUNTERMEASURES

Nethammer bypasses defenses that assume attacker-controlled local code or a separable hammering process. The paper therefore evaluates code analysis, performance-counter detection, memory isolation, and deployment mitigations.

  • Limits of existing defenses: Because Nethammer executes no attacker-controlled code, most conventional Rowhammer countermeasures do not prevent it.The attack’s memory accesses are generated by the kernel while processing network traffic.
  • Limits of existing defenses: Static code analysis cannot detect Nethammer, while performance-counter defenses cannot simply terminate the kernel’s packet-processing activity.Allocator-based isolation may work generally, but proposed isolation schemes are ineffective when the kernel performs the hammering.
  • Specific countermeasures: ANVIL in its current form does not detect one-location hammering, although an adapted version might work if its false-positive and false-negative rates are acceptable.The paper notes that this practicality question requires further evaluation.
  • Specific countermeasures: B-CATT would work against Nethammer but is considered impractical because it blocks too much memory.The scheme blacklists vulnerable locations rather than eliminating the underlying Rowhammer bug.
  • Mitigation recommendations: The paper recommends reviewing network stacks, treating uncached memory and clflush with extreme care, and reconsidering threat models when these mechanisms cannot be slowed or removed.For eviction-based Nethammer, avoiding severely restricted Intel CAT configurations or using ECC memory is suggested.

8 DISCUSSION

The discussion bounds Nethammer by hardware susceptibility, traffic requirements, device throughput, and DRAM characteristics. It also reports that modest DRAM-voltage increases did not eliminate bit flips in the tested systems.

  • Hardware requirements and limitations: Nethammer requires DRAM susceptible to Rowhammer bit flips, while ECC RAM can correct single-bit errors but not necessarily exploitable multi-bit errors.The authors note that cloud providers may offer hardware without ECC RAM, leaving some systems exposed.
  • Network traffic: The attack can generate large traffic spikes, but a few hundred milliseconds of traffic followed by longer pauses may reduce detectability by network monitoring.The experiments used up to 500 Mbit/s and observed one bit flip every 350 ms; row refresh occurs within 64 ms.
  • Mobile and embedded devices: Many embedded devices and WiFi chips may lack sufficient throughput, whereas newer processors and modems reaching 1.2 Gbit/s could provide enough packets for Nethammer.The paper identifies Qualcomm Snapdragon 845 and X20 Gigabit LTE as examples of higher-throughput hardware.
  • DRAM supply voltage: Reported Rowhammer bit flips have occurred on DRAM modules below 1.5 volts, including DDR3, DDR4, LPDDR2, LPDDR3, and LPDDR4.The paper connects the reported vulnerability range with reductions in DRAM voltage across manufacturing generations.
  • DRAM supply voltage: Increasing DRAM voltage by 0.2 V caused no significant change in bit-flip counts on three tested systems.The tests covered two DDR4 systems and one DDR3 system, and future work is proposed on other voltage-related parameters.

9 CONCLUSION

Nethammer demonstrates that Rowhammer can be conducted remotely without attacker-controlled code on the victim. The attack can induce bit flips, damage system integrity, and expose systems to persistent denial of service.

  • Nethammer induces multiple bit flips per hour on real-world systems without attacker-controlled code on the victim.
  • Adaptive memory-controller page policies are vulnerable to one-location hammering, although insufficient network capacity prevented Nethammer on the tested ARM device.
  • Remote Rowhammer invalidates assumptions behind defenses designed for local attacks and requires re-evaluating devices that forbid attacker-controlled code execution.

A KERNEL ACCESSES FOR NETWORK PACKETS

Table 2 reports funccount results for UDP-related functions while the victim system is flooded with UDP packets.

  • Table 2 reports results produced by the funccount script from the perf framework.
  • The reported functions are selected because their names contain udp.
  • The measurements are collected while the targeted system is flooded with UDP packets.
Loading 1805.04956v1…