ZenHammer: Rowhammer-Angriff auf AMD-Zen-basierte Plattformen

 (comsec.ethz.ch)
1 Punkte von GN⁺ 2024-03-26 | 1 Kommentare | Auf WhatsApp teilen
  • Auch auf AMD-Zen-2- und Zen-3-DDR4-Systemen mit TRR-Abschwächungen treten Rowhammer-Bitflips auf, sodass AMD-Plattformen ebenfalls eine reale Angriffsfläche darstellen können
  • Das Forschungsteam hat mit einer auf AMD angepassten DRAMA-Methode geheime DRAM-Adressfunktionen reverse-engineert und festgestellt, dass wegen der Neuzuordnung von Systemadressen ein Offset für physische Adressen berücksichtigt werden muss
  • Der ZenHammer-Fuzzer löste bei 10 DDR4-Geräten, darunter Samsung, Micron und SK Hynix, Bitflips aus: 7 unter Zen 2 und 6 unter Zen 3; Zen-3-Geräte zeigten sich dabei anfälliger als Intel Coffee Lake
  • Angriffe auf bestehende Page Tables, die Beschädigung öffentlicher RSA-2048-Schlüssel und ein Angriff auf sudoers.so waren auf 7/6/4 Geräten konfigurierbar; die durchschnittliche Zeit bis zum Finden ausnutzbarer Bitflips betrug 164/267/209 Sekunden
  • In der DDR5-Evaluierung auf Zen 4 traten bei 1 von 10 Geräten rund 42.000 Bitflips auf, während die übrigen 9 Geräte nicht betroffen waren; für DDR5 ist daher weitere Forschung zu Mustern nötig

Rowhammer-Bitflips auch auf AMD Zen

  • ZenHammer löst Rowhammer-Bitflips auf AMD-Zen-2- und Zen-3-Systemen mit DDR4-Geräten aus, bei denen TRR-Abschwächungen aktiv sind
  • Es wurde bestätigt, dass AMD-Systeme ebenso wie Intel-Systeme Rowhammer-Schwachstellen aufweisen können
  • Angesichts eines Marktanteils von AMD bei x86-Desktop-CPUs von etwa 36 % ist die Angriffsfläche nicht klein
  • DRAM-Geräte lassen sich nach ihrer Auslieferung nur schwer nachträglich korrigieren, und frühere Arbeiten haben gezeigt, dass Rowhammer-Angriffe in verschiedenen Umgebungen praktisch einsetzbar sein können

Reverse Engineering von AMD-DRAM-Adressfunktionen und Hammering-Optimierung

  • Die DRAMA-Methode wurde für AMD-Systeme angepasst, um geheime DRAM-Adressfunktionen per Reverse Engineering zu rekonstruieren
  • Für stabilere Ergebnisse wurde die Timing-Routine geändert
  • Wegen der Neuzuordnung von Systemadressen musste vor der Rekonstruktion der DRAM-Adressfunktion ein Offset für physische Adressen angewendet werden; so konnte die Adressfunktion vollständig wiederhergestellt werden
  • Eine Vorgehensweise, die nur die rekonstruierte Adressfunktion nutzt, führte nur zu einer begrenzten Zahl von Bitflips
    • Unter Zen 2 wurden Bitflips nur bei 5 von 10 Geräten nachgewiesen
    • Unter Zen 3 wurden bei 0 von 10 Geräten Bitflips nachgewiesen

Refresh-Synchronisierung und Befehlssequenzen

  • Wie in früheren Arbeiten wie SMASH und Blacksmith war Refresh-Synchronisierung ein wichtiger Faktor zum Auslösen von Bitflips
  • Auf AMD erwies sich ein Verfahren mit fortlaufenden Timing-Messungen auf nicht wiederholten Zeilen als wirksam für eine präzise und zuverlässige Refresh-Synchronisierung
  • Auf AMD-Zen+-/3-Systemen war die Aktivierungsrate nichtuniformer Rowhammer-Muster deutlich niedriger als bei Intel Coffee Lake
  • Die optimale Hammering-Befehlssequenz nutzte normale Loads per MOV und CLFLUSHOPT, um Aggressoren aus dem Cache zu flushen, in einem „Scatter“-Stil, bei dem unmittelbar nach dem Zugriff auf den Aggressor geflusht wird
  • Anders als bei Zen 2 war unter Zen 3 nach dem Flush kein expliziter Fence erforderlich
  • Auch Fence-Typ und Scheduling-Policy für Fences beeinflussten die Ergebnisse; das Forschungsteam schlug sechs Pattern-Awareness- und Cache-Avoidance-Policies vor und testete sie je Gerät 6 Stunden lang
    • Bei den meisten Zen-2-Geräten war SP_none optimal
    • In den meisten Zen-3-Fällen war SP_pair besser geeignet

Ergebnisse der DDR4-Evaluierung und Ausnutzbarkeit

  • Die Evaluierung wurde mit 10 DDR4-DRAM-Geräten durchgeführt, darunter Samsung, Micron und SK Hynix
  • Der ZenHammer-Fuzzer lief jeweils 3 Stunden lang mit Kombinationen aus den Fence-Typen mfence und sfence und den jeweiligen Fence-Scheduling-Policies
  • Nach jedem Lauf wurde mit allen gefundenen Mustern ein Minisweep über einen 4-MiB-Bereich durchgeführt, um das optimale Muster zu bestimmen; anschließend wurde das beste Muster der optimalen Policy über einen zusammenhängenden 256-MB-Speicherbereich gesweept
  • In der Folge traten bei 10 DDR4-DRAM-Geräten Bitflips auf: 7 unter Zen 2 und 6 unter Zen 3
  • Die Ausnutzbarkeit der Bitflips wurde anhand von drei Angriffen aus früherer Forschung bewertet
    • Ein Angriff auf die Page Frame Number eines Page-Table-Eintrags, um auf eine vom Angreifer kontrollierte Page-Table-Page zu pivotieren
    • Ein Angriff auf einen öffentlichen RSA-2048-Schlüssel, der die Wiederherstellung des zugehörigen privaten Schlüssels für die SSH-Host-Authentifizierung ermöglicht
    • Ein Angriff auf die Passwortprüfungslogik der Bibliothek sudoers.so, der die Erlangung von Root-Rechten ermöglicht
  • Die bestehenden Angriffe waren auf 7/6/4 Geräten konfigurierbar; die durchschnittliche Zeit bis zum Finden ausnutzbarer Bitflips betrug 164/267/209 Sekunden

DDR5-Evaluierung, veröffentlichter Code und Präsentationstermin

  • Auf AMD Zen 4 wurde auch die DDR5-DRAM-Funktion reverse-engineert und es wurden 10 DDR5-Geräte evaluiert
  • ZenHammer löste bei 1 von 10 DDR5-Geräten rund 42.000 Bitflips aus
  • Dies ist der erste öffentlich berichtete Fall von DDR5-Bitflips auf einem gewöhnlichen kommerziellen System
  • Bei den übrigen 9 DDR5-Geräten traten keine Bitflips auf; für DDR5-Geräte ist daher weitere Forschung nötig, um wirksamere Muster zu finden
  • Die vollständigen Details sind in dem Paper enthalten, das im August 2024 auf der USENIX Security 2024 vorgestellt wird
  • Der ZenHammer-Fuzzer-Code ist auf GitHub verfügbar und kann genutzt werden, um DRAM-Geräte auf AMD-Zen-2/3/4-CPUs auf Bitflips zu evaluieren
  • Da Rowhammer ein bekanntes branchenweites Problem ist, wurde ein allgemeiner Disclosure-Prozess nicht für erforderlich gehalten; AMD wurde jedoch am 26. Februar 2024 informiert, und auf Wunsch von AMD wurde bis zum 25. März 2024 auf eine Veröffentlichung verzichtet
  • Diese Seite war versehentlich am 21. März 2024 kurzzeitig online öffentlich zugänglich

Praktische Einschränkungen aus der FAQ

  • AMD-Systeme wurden zuvor weniger behandelt, weil in der ursprünglichen Rowhammer-Forschung die Zahl der Bitflips auf Intel-Systemen deutlich höher war, sich Folgearbeiten überwiegend auf Intel konzentrierten und mehr Informationen zur Mikroarchitektur von Intel-CPUs als zu AMD bekannt waren
  • Bei 3 von 10 DDR4-Geräten unter Zen 2 und 4 unter Zen 3 traten keine Bitflips auf; da diese Geräte aber auch unter Intel Coffee Lake nur wenige Bitflips zeigten, geht man davon aus, dass weitere Anpassungen des Fuzzers Bitflips sichtbar machen könnten
  • Die Evaluierung war auf 10 Geräte beschränkt, weil im Labor nur eine begrenzte Zahl von AMD-Zen-2/3-Systemen verfügbar war und einige Experimente lange Laufzeiten hatten; die zufällige Teilmenge umfasste Geräte aller drei DRAM-Anbieter
  • Zur Frage, warum JEDEC das Problem noch nicht behoben hat, wird erklärt, dass die Lösung von Rowhammer schwierig, aber nicht unmöglich ist; frühere Arbeiten wie ProTRR und REGA hätten dies gezeigt
  • Eine frühere Arbeit zu DDR3 zeigte, dass ECC Rowhammer nicht verhindert; da aktuelle DDR4-Geräte mehr Bitflips aufweisen, wird ECC nicht als vollständiger Schutz, sondern als Maßnahme bewertet, die eine Ausnutzung erschwert
  • Eine Verdopplung der Refresh-Rate verursacht Performance-Overhead und erhöhten Stromverbrauch und hat sich in früheren Arbeiten von Mutlu et al. und Frigo et al. als schwache Lösung erwiesen, die keinen vollständigen Schutz bietet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-26
Hacker-News-Kommentare

  • Ich bin einer der ursprünglichen Mitautoren des Rowhammer-Exploits. ECC ist weiterhin sehr wirksam darin, dieses Problem größtenteils von einem Sicherheitsproblem in ein Zuverlässigkeitsproblem zu verwandeln.
    Wenn man einen eigenen Server betreibt, ECC im Server hat und davon ausgehen kann, dass man einen Ausfall der Maschine durch nicht korrigierbare ECC-Fehler bemerkt, sind die Sicherheitsauswirkungen nicht besonders groß.
    Bei Cloud-Anbietern, die VMs auf Multi-Tenant-Hosts bereitstellen, kann das Bedrohungsmodell allerdings anders aussehen.
    In jedem Fall sollte man Maschinen ohne ECC vermeiden. TRR war schon damals, als Rowhammer gerade erst bekannt wurde, eine gescheiterte Abwehr, und solange sich die Ökonomie der DRAM-Fertigung nicht ändert, werden DRAM-Bitflips nicht verschwinden.

    • Wenn möglich, würde ich gern ECC-Speicher verwenden. Früher hatte ich einen TR 2920x mit ECC, jetzt nutze ich jedoch einen Ryzen 7950x ohne ECC.
      Ryzen unterstützt nur unbuffered ECC, und das ist bei gleicher Kapazität langsamer oder teurer als Nicht-ECC-Speicher oder beides.
      Die aktuelle Threadripper-Reihe unterstützt Registered ECC, aber für Heimanwender wie mich ist das bei Kosten, Threads und PCIe-Lanes in jeder Hinsicht zu viel.
    • Wenn „DRAM-Bitflips nicht verschwinden werden, solange sich die Ökonomie der DRAM-Fertigung nicht ändert“, dann scheint das ein stark genuges Argument für eine ECC-Speicherpflicht in allen Computern zu sein.
      Das Sicherheitsrisiko ist zu groß, und alles ist zu stark integriert, um diesen Wandel weiter aufzuschieben. Selbst Gamer mit einem reinen Gaming-PC werden wichtige Informationen auf dieser Maschine haben, daher ist schwer nachzuvollziehen, warum dieser Wandel bisher ausgeblieben ist.
    • Ich habe gehört, dass DDR2 gegen Rowhammer immun sei; ich frage mich, ob das tatsächlich stimmt oder ob es nur daran liegt, dass niemand es gründlich untersucht hat.
      Ich frage mich auch, ob wirklich nur SRAM immun ist.
    • AMD folgt inzwischen ebenfalls der Intel-artigen Marktsegmentierung und deaktiviert ECC bei den meisten Ryzen-CPUs.
      Garantiert wird es nur bei Pro und Threadripper, und bei einigen Desktop-Ryzen funktioniert es nur auf bestimmten Mainboards.
    • Es gibt Fragen, auf die ich in früheren Arbeiten keine zufriedenstellenden Antworten gefunden habe. Werden moderne Patrol-Read-Engines bei den Speicherzugriffsmustern so gesteuert, dass sie auf Rowhammer-artige Angriffe reagieren?
      Wie aggressiv müsste eine Patrol-Read-Engine DRAM scannen, um durch Rowhammer verursachten Bitflips sicher zuvorzukommen?
      Verändert sich das Bild mit ECC-Wörtern, die größer sind als die traditionellen 64+8, und mit Mehrbitfehlerkorrektur so stark, dass sich damit trotz musteranfälligem DRAM zuverlässigere Systeme bauen lassen?

  • Formulierungen wie „ECC kann Rowhammer nicht verhindern“ sind äußerst irreführend. Auch die zitierte Arbeit sagt: „0,65 % bis 7,42 % aller Bitflips verursachen stille Beschädigung, selbst wenn die ECC-Erkennung korrekt eingesetzt wird … in der AMD-1-Konfiguration bringen nicht korrigierbare Fehler das System zum Absturz.“
    Damit ein Angreifer auch nur einen einzigen ausnutzbaren Bitflip erhält, müsste er Dutzende Maschinenabstürze verursachen. Dutzende Maschinenabstürze bleiben nicht unbemerkt.
    Es ist gut, dass auf die miserable JEDEC-Reaktion auf Rowhammer hingewiesen wurde, aber man sollte ECC als kurzfristige Lösung nicht unterschätzen.

    • Ich frage mich, ob Betriebsteams, die das System verwalten, Verfahren haben, um so ein Phänomen als Angriff und nicht bloß als instabile Hardware zu erkennen.
    • Wenn ein bestimmter Rechner das Ziel ist, stimmt das wohl, aber wenn man einen Exploit wie mit einer Schrotflinte über Tausende Maschinen verteilt, kann man immer noch ein Botnet bekommen. Es wäre nur etwas kleiner.
    • Einer der Gründe, warum ich ECC für meinen Desktop zu Hause gekauft habe, war der Schutz vor Rowhammer.
      Es ist eine Zen2-TR-Plattform, und bei dieser Formulierung ist mir kurz das Herz in die Hose gerutscht. Das ist ziemlich irreführend.
    • Ich frage mich, ob es Empfehlungen für Client-Geräte mit ECC-Speicher gibt.

  • Ich frage mich, ob Hardware-Sicherheitsprobleme wie Rowhammer, Spectre und Meltdown für normale Nutzer tatsächlich ein reales Risiko darstellen.
    Ich hatte verstanden, dass Spectre und Meltdown vor allem bei Angriffen wie VM-Escape problematisch sind, also eher etwas, worum sich ein AWS-Ingenieur kümmern muss, und nicht einzelne Nutzer.

    • Die Lösung ist, JavaScript zu deaktivieren und keine nicht vertrauenswürdigen Apps auszuführen.
      Und da man sich damit von der modernen Gesellschaft abgekoppelt hat, kann man gleich in eine Hütte im Wald ziehen und Selbstversorger werden.
    • Aus der nüchternen Perspektive eines Hardware-Sicherheitsforschers sind die tatsächlich ausgenutzten Schwachstellen, die Durchschnittsnutzer betreffen, weit banaler und größtenteils softwarebasiert.
    • Alle sollten irgendeine Form einer Script-Allowlist-Erweiterung installieren und JavaScript nur auf Websites ausführen, denen sie wirklich vertrauen.
      Ich persönlich mag NoScript. Für Chrome weiß ich nicht so recht, was man nehmen sollte.
      Davon abgesehen … führt man normalerweise nicht ständig beliebige Programme aus dem Internet aus, oder?
      Bei dieser Art von Bugs hat man bisher nur an der Oberfläche gekratzt. Moderne Hardware ist so komplex, dass man kaum glauben kann, jemals alles zu finden.
    • Es gibt auch eine JavaScript-Implementierung, die Rowhammer im Browser ausführen kann: https://github.com/IAIK/rowhammerjs
    • Aus Sicherheitssicht ist der Webbrowser eine Art VM-Hypervisor, und jede Website hat gewissermaßen ihre eigene VM.
      Deshalb kann letztlich jeder betroffen sein.

  • Ich hatte DDR-Bit-Flip-Angriffe bisher nur sehr vage verstanden, aber als ich das ursprüngliche Hammertime-Paper gelesen habe, stellte sich heraus, dass es tatsächlich leicht zu lesen ist
    Ich habe es noch nicht ganz durch, aber es erklärt die Sache sehr verständlich. Den Begriff Bit Flip hatte ich unzählige Male gehört, ohne ihn je wirklich zu verstehen, aber dadurch habe ich endlich ein Gefühl dafür bekommen
    https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
    Es fühlte sich an, als hätte ich einen Einführungskurs in Elektrotechnik belegt. Dass das tatsächlich mit Fertigungsfehlern in der Hardware zusammenhängt, wusste ich überhaupt nicht
    Auch der Name Rowhammer wurde mir dadurch erst klar. Vielleicht bin ich einfach sehr spät dran und das ist für alle anderen längst bekannt
    „Wegen der extremen Dichte moderner DRAM-Arrays können kleine Fertigungsfehler eine schwache elektrische Kopplung zwischen benachbarten Zellen erzeugen. In Verbindung mit der extrem kleinen Kapazität solcher Zellen verlieren die Speicherzellen benachbarter Zeilen jedes Mal eine geringe Ladungsmenge, wenn eine DRAM-Zeile in einer Bank gelesen wird. Passiert das zwischen zwei Refresh-Zyklen häufig genug, können die betroffenen Zellen so viel Ladung verlieren, dass sich der gespeicherte Bitwert umkehrt; das nennt man einen ‚disturbance error‘ oder neuerdings Rowhammer“

    • Wenn man nur diese Erklärung liest, klingt es so, als sei das ein unvermeidbares Grundproblem beim Bau von DRAM, aber das ist es nicht
      DRAM-Hersteller haben die Grenzen einfach bis zum Äußersten ausgereizt. Es geht um Profit
      Das ist nicht anders als bei Ford, das entschied, dass die Vergleichskosten in den Pinto-Klagen wegen Verletzungen und Todesfällen niedriger seien als die Kosten für eine Konstruktionsänderung

  • Ich frage mich, ob Secure Memory Encryption hier hilft
    https://www.amd.com/en/developer/sev.html

    • Es hilft schon, aber man kann dadurch stark an Zuverlässigkeit verlieren
      Schon ein einzelner Bit Flip kann zu einem fatalen Fehler führen

  • Ich kenne mich mit Hardware-Sicherheit zu wenig aus und frage mich, ob das eine von vielen unvermeidlichen Schwachstellen ist, die durch CPU-Optimierungen entstehen, und in der Praxis eher in die Kategorie mit geringer Umsetzbarkeit fällt

    • Man kann es eher als noch schlimmer ansehen. Das entsteht aus der Physik von DRAM
      Es passiert auf einer viel tieferen Ebene als Grenzfälle von Funktionen, die über Side-Channels Informationen durchsickern lassen
      Daten werden als kleine Ladungen in einem Raster gespeichert, und wenn man nahegelegene Rasterpunkte oft genug umschaltet, kann man bewirken, dass ein Teil der Ladung zur Zielladung hin ausläuft
      Je kleiner die Ladung und je näher sie beieinander liegen, desto einfacher werden Rowhammer-Angriffe. Gleichzeitig gilt: Je kleiner die Ladung und je dichter sie liegen, desto schneller, billiger, dichter und effizienter wird RAM
      Es gibt Gegenmaßnahmen, aber man ist bereits bis an die Grenzen gegangen
    • Das ist ein RAM-Problem und kein CPU-Problem

  • Ich frage mich, ob das selbst dann funktioniert, wenn vollständige Speicherverschlüsselung, Poisoning und Adress-XOR aktiviert sind

    • Mit Speicherverschlüsselung führt es nicht zur Übernahme des Systems, sondern nur zu einem Systemabsturz
      Deshalb ist Speicherverschlüsselung sicherer

  • Wenn „ZenHammer bei 9 von 10 Geräten keine Flips auslösen konnte … weitere Forschung nötig ist, um für DDR5-Geräte wirksamere Muster zu finden“, dann scheint für DDR5 wohl noch etwas Zeit zu bleiben
    Ich frage mich, ob jemand weiß, ob das auch LPDDR5x betrifft

    • Die DRAM-Schnittstelle ist vom eigentlichen Speicherarray recht gut getrennt
      Deshalb ist nicht die entscheidende Frage, ob es sich um DDR5, LPDDR5(x), GDDR6(x) oder HBM3(e) handelt
      Entscheidend sind eher Implementierungsdetails, die im Ermessen des Herstellers liegen, etwa On-Die-ECC

  • Zen 2 und 3 werden erwähnt, aber ich frage mich, ob es irgendwelche Informationen zu Zen 1 gibt
    Gilt das einfach genauso?