PaperlayerView exact revision on arXiv

Source-linked AI summary

Another Flip in the Wall of Rowhammer Defenses

Daniel Gruss, Moritz Lipp, Michael Schwarz, Daniel Genkin, Jonas Juffinger, Sioli O'Connell, Wolfgang Schoechl, Yuval Yarom

arXiv:1710.00551v2cs.CR

TL;DR

Existing Rowhammer defenses have not established that attacks are prevented when their assumptions are combined. This paper introduces attack, exploitation, placement, and concealment primitives, and reports attacks that evade previously proposed commodity-system countermeasures.

  • Problem

    The paper addresses insufficient understanding of whether existing Rowhammer defenses prevent privilege-escalation attacks, including when multiple defenses are combined.

  • Method

    The paper develops one-location hammering, opcode flipping, memory waylaying, and an Intel SGX-based Rowhammer enclave to bypass defense assumptions.

  • Results

    The attacks evade previously proposed countermeasures for commodity systems and support personal-computer privilege escalation and coordinated cloud denial of service.

  • Takeaways & Limitations

    Rowhammer defenses for commodity systems remain incomplete against the paper’s combined attack and exploitation primitives.

  • Takeaways & Limitations

    The native attack scenario likely requires an enclave signed by a signing entity such as Intel or a BIOS vendor.

Abstract

from arXiv · show

The Rowhammer bug allows unauthorized modification of bits in DRAM cells from unprivileged software, enabling powerful privilege-escalation attacks. Sophisticated Rowhammer countermeasures have been presented, aiming at mitigating the Rowhammer bug or its exploitation. However, the state of the art provides insufficient insight on the completeness of these defenses. In this paper, we present novel Rowhammer attack and exploitation primitives, showing that even a combination of all defenses is ineffective. Our new attack technique, one-location hammering, breaks previous assumptions on requirements for triggering the Rowhammer bug, i.e., we do not hammer multiple DRAM rows but only keep one DRAM row constantly open. Our new exploitation technique, opcode flipping, bypasses recent isolation mechanisms by flipping bits in a predictable and targeted way in userspace binaries. We replace conspicuous and memory-exhausting spraying and grooming techniques with a novel reliable technique called memory waylaying. Memory waylaying exploits system-level optimizations and a side channel to coax the operating system into placing target pages at attacker-chosen physical locations. Finally, we abuse Intel SGX to hide the attack entirely from the user and the operating system, making any inspection or detection of the attack infeasible. Our Rowhammer enclave can be used for coordinated denial-of-service attacks in the cloud and for privilege escalation on personal computers. We demonstrate that our attacks evade all previously proposed countermeasures for commodity systems.

I. INTRODUCTION

Rowhammer enables unauthorized DRAM bit changes and has supported attacks across security boundaries, while commodity defenses provide incomplete protection. This paper introduces attack and exploitation primitives that bypass the assumptions of these defenses, including when combined.

  • Motivation: Rowhammer allows unprivileged software to induce unauthorized changes in physically adjacent DRAM locations.Prior attacks include privilege escalation, sandbox escapes, cloud attacks, cryptographic fault attacks, and mobile root compromise.
  • Prior defenses: Existing defenses include software mitigations, static analysis, performance monitoring, access-pattern monitoring, memory-placement controls, and physical isolation.Several software countermeasures have already been bypassed, while some others address only specific attack techniques.
  • Research question: The paper asks whether Rowhammer privilege escalation remains possible in the presence of some or all proposed countermeasures.The question targets the completeness of defense assumptions and protections.
  • Contributions: Opcode flipping targets userspace instructions, bypassing memory-layout defenses that isolate kernel pages from userspace pages.The technique modifies binary opcodes predictably and targets malicious instruction changes rather than kernel-page bits.
  • Contributions: Intel SGX hides the attack from the operating system and user by protecting enclave memory and excluding enclave activity from CPU performance counters.This defeats countermeasures based on performance-counter monitoring and application-code or instruction-stream analysis.
  • Attack scenarios: The resulting attacks apply to personal computers and cloud systems, including root privilege escalation and coordinated cloud denial of service.The paper reports a Rowhammer enclave for both attack scenarios.

C. Paper Outline

The paper moves from Rowhammer background and prior attack techniques to its defense analysis and attack construction. It explains how hammering, placement, and exploitation techniques support deterministic attacks.

  • Background: Rowhammer arises when rapid accesses to adjacent DRAM rows induce bit errors, requiring cache-bypassing techniques such as flushing or eviction.The paper then introduces techniques for obtaining bit flips in target rows.
  • Hammering techniques: Single-sided hammering accesses one adjacent row, whereas double-sided hammering accesses rows on both sides of the target and generally needs partial physical-mapping knowledge.Single-sided hammering may still use multiple addresses in the same DRAM bank.
  • Prior exploitation: Earlier reliable attacks used memory spraying, grooming, or page deduplication to make exploitable bit flips more deterministic.These techniques supported privilege escalation, sandbox escapes, and cryptographic-key compromise.

B. Rowhammer Defenses

Rowhammer defenses seek to detect attacks, neutralize bit flips, or eliminate the underlying bug, but practical commodity-system protections remain limited. SGX also creates both concealment opportunities and system-wide failure risks.

  • Defense goals: Defense strategies detect attacks, neutralize bit flips, or eliminate the Rowhammer bug.Detection includes static analysis and performance-counter monitoring, while neutralization relies on memory placement and related controls.
  • Commodity-system scope: Elimination defenses are impractical or require hardware changes, so commodity systems rely primarily on detection or neutralization.One evaluated blacklist would block more than 95 % of memory on several systems.
  • SGX background: SGX protects enclave code and data with confidentiality, integrity, and freshness mechanisms that remove DRAM from the trusted computing base.Integrity failures prevent unverified data from reaching the cache and can halt the system until reboot.
  • SGX attack surface: Enclave memory is inaccessible to other processes and the operating system, although shared DRAM rows still permit cross-enclave DRAMA attacks.This creates a distinction between memory sharing and physical row sharing.
  • Related work: A concurrent work independently proposed a denial-of-service attack running Rowhammer inside an SGX enclave.The paper compares that attack with its own observations later.

III. CATEGORIZATION OF STATE-OF-THE-ART DEFENSES FOR COMMODITY SYSTEMS

The paper categorizes commodity-system defenses by their underlying assumptions and evaluates attack primitives against those assumptions. One-location hammering and memory waylaying specifically challenge detection and placement-based protections.

  • Defense classes: The five commodity-system defense classes are static analysis, performance-counter analysis, memory-access-pattern analysis, physical isolation, and prevention of conspicuous memory footprints.The categorization focuses on detection and neutralization defenses applicable to commodity systems.
  • Detection assumptions: Static analysis assumes attack code can be accessed, while performance-counter monitoring assumes counters are available and include the attacker’s operations.Runtime detection can theoretically miss an attack before it is stopped.
  • Detection mechanisms: Performance-counter defenses typically identify cache-miss activity, while access-pattern defenses look for high-frequency accesses to multiple addresses in one DRAM bank.ANVIL combines cache-miss-ratio monitoring with address-level analysis using Intel PEBS.
  • One-location hammering: Modern memory-controller policies that preemptively close rows may enable one-location hammering, which repeatedly reopens a single DRAM row.The paper reports that this process can drain sufficient charge to induce bit flips.
  • Memory waylaying: Memory waylaying uses page-cache eviction and a prefetch side channel to place target data at a vulnerable physical location without memory exhaustion.Once positioned, the target binary page is struck with a Rowhammer bit flip and exploited.

VI. OPCODE FLIPPING

Opcode flipping targets bits in executable instructions rather than page-table metadata, using valid opcode substitutions to alter program decision logic. The paper identifies 29 exploitable offsets in sudo’s password-verification logic, enabling incorrect passwords to be treated as correct.

  • Opcode flipping: Opcode flipping targets bit flips in shared binaries or libraries, modifying instructions rather than page-number fields in attacker-generated page tables.The technique applies to binary pages that exist only once in memory and cannot be sprayed.
  • Opcode flipping: A single bit flip can transform x86 JE into valid alternatives such as JNE, JBE, JO, JL, PUSHQ, XORB, or HLT.The example illustrates how small opcode changes can produce substantially different instruction semantics.
  • Opcode flipping: Flips in TEST instructions or conditional jumps can change decision logic by altering the zero flag or the branch condition.The paper focuses on these instructions because tests and conditional jumps control decisions in virtually all computer programs.
  • Case study: On Ubuntu 17.04, the authors analyzed the sudo binary and sudoers.so as prominent targets among 16 root-owned setuid binaries.They focused on bypassing sudo password verification rather than the separate sudoers authorization check.
  • Case study: 29 offsets in sudo were identified where bit flips break password verification, causing incorrect passwords to be accepted through altered tests or conditional jumps.The identified offsets affect either the password-verification test or its conditional jump.
  • Case study: Because bit-flip positions are uniformly distributed over pages, any of the 29 identified sudo offsets can be targeted for root privilege escalation.The paper provides the offsets and opcode effects in Appendix A.

VII. ONE-LOCATION ROWHAMMER

One-location hammering induces Rowhammer bit flips while repeatedly reopening only one DRAM row, challenging defenses that assume multiple-row conflicts. Its effectiveness is lower than conventional techniques but sufficient for targeted offsets, while memory waylaying provides stealthy physical page placement without memory exhaustion.

  • VII. ONE-LOCATION ROWHAMMER: One-location hammering reopens one DRAM row permanently instead of directly inducing row conflicts between multiple rows.It uses a Flush+Reload loop on one randomly chosen address and does not require virtual-to-physical address mappings.
  • VII. ONE-LOCATION ROWHAMMER: Single-sided hammering flipped 25 722 of 32 768 bit offsets (78.5%), a slightly more uniform distribution than double-sided hammering’s 25 223 offsets (77.0%).54.1% of single-sided flips and 51.7% of double-sided flips changed values from 0 to 1.
  • VII. ONE-LOCATION ROWHAMMER: On Skylake, one-location hammering flipped 11 969 of 32 768 bit offsets (36.5%) across at least one 4 kB-aligned region.51.6% of these bit flips changed values from 0 to 1.
  • VII. ONE-LOCATION ROWHAMMER: One-location hammering is less effective than double-sided and single-sided hammering, yet it still drains sufficient DRAM charge to induce bit flips.This establishes the previously unknown effect underlying the technique.
  • VII. ONE-LOCATION ROWHAMMER: Bit flips were reproduced on Haswell for all techniques, whereas one-location flips were rare and unreliable on Ivy Bridge using an open-page policy.Across all three systems, 0-to-1 and 1-to-0 flips had approximately equal probability.
  • VIII. MEMORY WAYLAYING: Memory waylaying uses page-cache eviction and a prefetch side-channel oracle to place target pages at attacker-chosen physical locations without spraying or grooming.Memory chasing is a faster variant that sacrifices stealth but not reliability.

A. Prefetch-based Prediction Oracle

The attack combines a prefetch-based address-translation oracle with replacement-aware page-cache eviction to place target pages at exploitable physical locations without exhausting memory. The approach is stealthier but slower than memory chasing.

  • A. Prefetch-based Prediction Oracle: The prefetch address-translation oracle monitors whether virtual addresses map to attacker-relevant physical locations and triggers hammering when a match appears.It is used first to identify exploitable offsets and again during page placement.
  • A. Prefetch-based Prediction Oracle: 3737 seconds of stability testing produced no false positives, while the optimized oracle found a true positive every 4.5 seconds on average.A performance-optimized version measured each address in under 50 milliseconds without false positives, but with a higher false-negative rate.
  • B. Page Cache Eviction: Page-cache eviction forces subsequent file accesses to map target pages to new physical locations on both Windows and Linux.The attacker evicts cached file pages so the operating system allocates fresh physical pages when the files are accessed again.
  • B. Page Cache Eviction: Replacement-aware eviction fills the page cache with read-only executable pages while leaving occupied memory untouched, avoiding memory pressure and out-of-memory situations.Linux prioritizes nonexecutable pages for eviction but eventually evicts executable pages when the cache is filled with read-only executable pages.
  • C. Positioning Memory Pages: Memory waylaying repeatedly evicts and reloads a target page until the oracle detects placement at a vulnerable physical location.The technique exploits otherwise unused memory, so it has no impact on memory utilization and only negligible impact on overall system performance.
  • C. Positioning Memory Pages: Memory chasing moves target pages faster than memory waylaying but sacrifices stealth and requires many fork system calls occupying one CPU core.Moving a page averaged 36.7 µs with memory chasing versus 2.68 s with memory waylaying.

IX. EVALUATION OF ATTACKS IN NATIVE AND CLOUD ENVIRONMENTS

The evaluation examines Rowhammer attacks in cloud and local environments, including SGX-based coordinated denial of service and privilege escalation. The cloud attack was demonstrated on a representative server setup, while SGX attacks halted systems after EPC bit flips.

  • Cloud Environment: The cloud scenario uses an unprivileged SGX enclave to identify vulnerable servers and coordinate a distributed denial-of-service attack.The attack omits opcode flipping and memory waylaying because its goal is denial of service rather than privilege escalation.
  • Cloud Environment: The seek phase templates many hosts for possible bit flips over multiple hours, after which the destroy phase simultaneously triggers EPC bit flips within seconds to minutes.A bit flip in EPC memory locks the memory controller and halts the machine until reboot.
  • Cloud Environment: Only 3 bit flips occurred during an 8-hour test on the cloud-like Haswell-EP system, but the authors report that this sufficed for their denial-of-service attack.The system used susceptible DDR4-2133 DIMMs, while lower clock frequency and doubled refresh rates made flips rarer.
  • Cloud Environment: The SGX experiment reproducibly crashed the Skylake system within 10 seconds when hammering DRAM rows used by the EPC.The locked memory controller forced a manual power-off, and some subsequent boots did not progress beyond the BIOS.
  • Cloud Environment: The authors conclude that SGX enables hard-to-trace, coordinated denial-of-service attacks against cloud machines.They identify this as a significant security risk for cloud providers because it harms availability and reliability.

B. Abusing SGX to Hide Privilege-Escalation Attacks

The privilege-escalation attack hides Rowhammer activity inside an SGX enclave and combines predictable opcode flipping with memory positioning. Its hammering phase modifies a target binary, enabling authentication bypass in the sudo example.

  • B. Abusing SGX to Hide Privilege-Escalation Attacks: The attack uses an unprivileged SGX enclave to evade defenses based on static analysis and memory-access monitoring.The enclave hides its memory contents from the operating system and excludes activity from CPU performance counters.
  • B. Abusing SGX to Hide Privilege-Escalation Attacks: In the sudo example, opcode flipping skips authentication checks and provides root privileges on an up-to-date Ubuntu distribution.The authors report that all attack steps were mountable in practice on an i7-6700K.
  • B. Abusing SGX to Hide Privilege-Escalation Attacks: Offline preparation builds a database of exploitable bit-flip offsets for binaries and libraries; the authors identified 29 exploitable offsets in sudo.Online preparation checks whether the target system’s binary and library versions appear in the database.
  • B. Abusing SGX to Hide Privilege-Escalation Attacks: Templating uses single-sided or one-location hammering on memory-mapped files to find physical pages containing exploitable bit flips without significant resident-memory growth.For the evaluated scenario, one-location hammering took 47.3 hours before waylaying and 1.3 hours before memory chasing.
  • B. Abusing SGX to Hide Privilege-Escalation Attacks: Memory waylaying waits for a vulnerable target binary or library page to reach an exploitable physical location, using the prefetch prediction oracle to detect placement.Once placement is detected, the enclave performs predictable opcode flipping with one-location hammering.
  • B. Abusing SGX to Hide Privilege-Escalation Attacks: The hammering phase takes only a few milliseconds and produces an unauthorized modification of the target binary after verifying the flipped bit.The modified binary page is then used in the exploitation phase.
  • B. Abusing SGX to Hide Privilege-Escalation Attacks: The attack demonstrates that existing commodity-system countermeasures are incomplete and that their underlying assumptions require refinement.This is the paper’s stated conclusion about the evaluated privilege-escalation attack.

X. DISCUSSION

The paper identifies limitations involving enclave signing, OS observability, future integrity defenses, and manual opcode-flip analysis. It also notes uncertainty about whether signing can constrain attacks when non-signed enclaves are deliberately run.

  • Limitations: Native attacks likely require a Rowhammer enclave signed by Intel or a BIOS vendor, although similar investigations suggest malware can reach app stores.The signing requirement is presented as a practical limitation, but the paper questions its effectiveness.
  • Limitations: Cloud providers may run non-signed user enclaves, allowing attackers to run the attack and requiring another SGX defense.The paper specifically considers non-signed enclaves plausible in secure cloud computation.
  • Limitations: Memory waylaying remains observable through OS allocation patterns, but legitimate high-memory workloads make those patterns ambiguous.The paper gives trusted video processing and large encrypted database operations as examples of legitimate high-memory use.
  • Limitations: Future software defenses might check binary integrity and terminate processes after detecting an integrity failure.The paper presents this as a possible future defense rather than an evaluated countermeasure.
  • Limitations: The effectiveness of enclave signing is uncertain because signing review has not yet been deployed and users or businesses can deliberately run non-signed enclaves.Microsoft is cited as already running non-signed enclaves on Azure confidential computing.
  • Limitations: Opcode-flip target identification currently requires manual range selection and grouping of successful execution results.The authors identify full automation and compiler-enforced multi-flip requirements as future-work directions.

B. Rowhammer mitigations in hardware

The discussion argues that software defenses remain difficult because Rowhammer triggering variants are incompletely known, while hardware and SGX design choices introduce distinct protection and system-level risks.

  • Rowhammer mitigations in hardware: Software-based Rowhammer countermeasures remain difficult because not all variants of triggering the Rowhammer bug are known.The paper also recommends considering related fault attacks when designing future defenses.
  • Hardware defenses: ECC RAM corrects 1-bit errors and IBM Chipkill can recover from 3-bit errors, but uncorrectable multi-bit flips may remain exploitable or cause denial of service.ECC support is limited on commodity systems: modern AMD Ryzen processors support it, while Intel restricts it to server CPUs.
  • Hardware defenses: LPDDR4 implements TRR and MAC, yet bit flips have still been reported; doubling refresh rates is insufficient and further increases impose excessive performance costs.The cited phone had 4 GB of LPDDR4 memory.
  • Hardware defenses: RAIM makes Rowhammer attacks infeasible by requiring multiple bit flips across different rows and modules to produce an uncorrectable error.RAIM is described as a memory analogue of RAID for IBM zEnterprise servers.
  • Hardware defenses: Probabilistically opening adjacent or non-adjacent rows refreshes vulnerable rows before bit flips occur and is proposed as a future-hardware mitigation.These approaches target repeated opening and closing of a row during ongoing Rowhammer attacks.
  • SGX: SGX hides the attack from defense mechanisms, including performance-counter monitoring and application-code or instruction-stream analysis.The paper characterizes this concealment as intentional SGX behavior while raising the problem of harmful enclave code.
  • SGX: SGX can halt an entire cloud system, creating a denial-of-service risk; stopping only enclaves and returning host error codes is proposed as safer.The paper frames this as a design change for cloud systems.
  • Overall assessment: The combined attack defeats state-of-the-art defenses, with one-location hammering requiring only one constantly open DRAM row and a 3.3 slowdown factor.Opcode flipping targets userspace sudo binaries, while memory waylaying replaces spraying and grooming.

APPENDIX

The appendix models total attack runtime from templating, memory waylaying, flipping, and physical-memory-dependent terms. Its test-system parameters yield an optimization minimum at n = 50.

  • Bitflips in sudo: The sudoers.so offsets listed in Table IV modify opcodes to skip the privilege check and elevate an unprivileged process to root.The table concerns Ubuntu 17.04 and sudo version 1.8.19p1.
  • Runtime model: The runtime equation combines physical memory P, waylaying time W, flip rate F, exploitable offsets E, and optimization parameter n.n is the number of bit flips found during templating; it affects both templating and waylaying runtime.
  • Runtime model: On the test system, P = 12 gigabytes, W = 2.68 seconds, F = 0.67, and E = 29.These values are substituted into the runtime model for the attack.
  • Runtime model: The runtime function reaches its minimum at n = 50.The appendix identifies this as the minimizing templating optimization parameter.
  • Runtime comparison: Figure 5 compares expected total runtime across hammering techniques and numbers of exploitable bit offsets.The runtime includes templating, memory waylaying, and chasing.

C. Memory Basics, Policies, and their Influence on One-Location Hammering

DRAM row-buffer behavior and memory-controller policies shape the latency and row-activation patterns relevant to one-location hammering. Access reordering and combining can reduce the bit flips produced by this technique.

  • Memory basics: DRAM accesses open rows into row buffers, while closing a row writes the buffered data back to the cells.
  • Memory basics: Row hits have low latency, whereas row conflicts require closing, precharging, and reopening rows and can reach 200% of row-hit latency.
  • Memory-controller policies: Open-page policies keep recently accessed rows open, benefiting latency, power consumption, and bank utilization when accesses are infrequent.
  • Memory-controller policies: Closed-page policies can improve performance under many accesses by immediately closing rows and precharging banks for new activations.
  • Influence on one-location hammering: Memory controllers can reorder and combine accesses, reducing row activations and thereby lowering one-location hammering’s bit-flip rate.
Loading 1710.00551v2…