Bits, die von selbst umkippen: Rowhammer und die physikalische Schwachstelle des Arbeitsspeichers

Der Aufhänger: Ein Angriff, der keine Lücke im Code braucht

Die meisten Sicherheitslücken, über die wir sprechen, sind Fehler im Denken. Ein Programmierer hat vergessen, eine Eingabe zu prüfen; ein Protokoll erlaubt einen Zustand, den niemand vorhergesehen hat; eine Bibliothek vertraut Daten, die sie nicht hätte vertrauen dürfen. Man kann solche Fehler finden, melden, patchen. Die Software wird korrigiert, die Lücke schließt sich, und die Welt dreht sich weiter.

Rowhammer ist von einer anderen Art. Hier ist kein Zeile Code fehlerhaft. Das Betriebssystem tut genau das, was es soll, die Speicherverwaltung arbeitet korrekt, die Zugriffsrechte sind sauber gesetzt. Und dennoch kann ein unprivilegiertes Programm – eines, das keinerlei besondere Rechte besitzt, vielleicht sogar in einer Webseite als JavaScript läuft – aus seinem zugewiesenen Speicherbereich ausbrechen und in fremden Speicher hineingreifen, den es niemals hätte berühren dürfen. Es tut dies nicht, indem es eine verbotene Adresse liest, sondern indem es seine eigenen, völlig legalen Speicherzellen so schnell und so oft ausliest, dass in den benachbarten Zellen einzelne Bits umkippen. Der Angreifer schreibt nirgendwo hin, wo er nicht darf. Er klopft nur an eine Wand, bis auf der anderen Seite etwas zu Boden fällt.

Diese physikalische Nebenwirkung des Klopfens – im Englischen hammering, daher der Name – verwandelt eine Eigenschaft der Hardware in eine Waffe. Sie durchbricht die vielleicht grundlegendste Annahme der gesamten Computersicherheit: dass ein Speicherzugriff nur die Zelle verändert, die er adressiert, und alle anderen in Ruhe lässt. Bei Rowhammer stimmt das nicht mehr. Der Speicher wird undicht, nicht im übertragenen, sondern im buchstäblichen, elektrischen Sinn.

Für jemanden wie Sven – Senior AI Engineer mit einem Bein in der Cloud-Architektur und einem in der IT-Sicherheit – ist Rowhammer aus einem doppelten Grund lehrreich. Erstens zeigt es, wie eine rein physikalische Eigenschaft, die die Speicherhersteller aus Kostengründen in Kauf nehmen, sich in ein handfestes Sicherheitsproblem verwandelt, gegen das keine noch so korrekte Software immun ist. Zweitens ist die zwölfjährige Geschichte von Rowhammer eine Musterstudie eines Rüstungswettlaufs: Jede Gegenmaßnahme der Industrie wurde von der Forschung durchbrochen, jede neue Speichergeneration, die das Problem lösen sollte, fiel erneut. Dieser Artikel nimmt dich auf die ganze Strecke mit – von der Physik der Speicherzelle über die erste Entdeckung 2014 und die Verwandlung in echte Angriffe bis zum Fall der aktuellen DDR5-Generation im Jahr 2025.

Teil 1: Wie ein Arbeitsspeicher funktioniert – und warum er von Natur aus vergesslich ist

Um zu verstehen, warum Bits kippen, muss man wissen, wie sie überhaupt gespeichert werden. Der Arbeitsspeicher moderner Computer ist DRAM – Dynamic Random Access Memory. Das Wort „dynamisch" ist der Schlüssel zum ganzen Problem.

Eine einzelne DRAM-Speicherzelle ist von verblüffender Einfachheit: Sie besteht aus genau einem winzigen Kondensator und einem Transistor, der als Schalter dient. Der Kondensator hält eine elektrische Ladung – ist er geladen, steht die Zelle für eine Eins, ist er entladen, für eine Null (oder umgekehrt, je nach Konvention). Diese Sparsamkeit – ein Kondensator, ein Transistor pro Bit – ist der Grund, warum DRAM billig und dicht ist und warum ein moderner Speicherriegel viele Milliarden Bits auf wenigen Quadratzentimetern unterbringt.

Der Preis dieser Einfachheit ist Vergesslichkeit. Ein Kondensator dieser Größe hält seine Ladung nicht. Er ist wie ein Eimer mit einem feinen Leck: Innerhalb von Sekundenbruchteilen sickert die Ladung weg, und die gespeicherte Information würde verblassen. Deshalb muss DRAM aufgefrischt werden – der englische Begriff ist Refresh. In regelmäßigen Abständen liest der Speichercontroller jede Zelle aus und schreibt ihren Wert sofort wieder zurück, füllt also den Eimer nach, bevor er leerläuft. Der JEDEC-Standard schreibt vor, dass jede Zeile innerhalb eines Refresh-Fensters von 64 Millisekunden (bei DDR5 unter bestimmten Bedingungen 32 ms) mindestens einmal aufgefrischt werden muss. Genau diese ständige, verborgene Nachfüllarbeit macht den Speicher „dynamisch".

Die Zellen sind nicht wahllos angeordnet, sondern in einem Gitter aus Zeilen und Spalten organisiert, wie ein riesiges Schachbrett. Um Daten zu lesen, aktiviert der Controller zunächst eine ganze Zeile (englisch row): Er öffnet die Transistoren dieser Zeile, wodurch die Ladungen der Kondensatoren auf die sogenannten Bitleitungen fließen und von Leseverstärkern (sense amplifiers) erfasst werden. Erst danach kann eine einzelne Spalte innerhalb dieser Zeile ausgelesen werden. Dieses „Öffnen" einer Zeile nennt man Aktivierung (ACT), das anschließende Schließen Precharge. Der springende Punkt: Jede Aktivierung schickt einen kleinen elektrischen Puls durch die Zeile. Und dieser Puls bleibt nicht folgenlos für die Nachbarn.

Teil 2: Die Entdeckung – wenn das Klopfen die Wand durchdringt

Im Jahr 2014 veröffentlichte eine Forschergruppe um Yoongu Kim (damals Carnegie Mellon University, gemeinsam mit Intel Labs) auf der Architekturkonferenz ISCA eine Arbeit mit dem programmatischen Titel „Flipping Bits in Memory Without Accessing Them" – Bits im Speicher umkippen, ohne auf sie zuzugreifen. Das war keine bloße Theorie: Die Gruppe testete 129 handelsübliche DDR3-Module verschiedener Hersteller und stellte fest, dass die große Mehrheit ein und dasselbe unheimliche Verhalten zeigte.

Der Effekt lautet so: Wenn man eine bestimmte Zeile im Speicher sehr oft und sehr schnell hintereinander aktiviert – Hunderttausende Male innerhalb eines einzigen 64-Millisekunden-Refresh-Fensters –, dann kippen mit hoher Wahrscheinlichkeit einzelne Bits in den unmittelbar benachbarten Zeilen um. Die immer wieder aktivierte Zeile heißt Aggressorzeile (aggressor row), die betroffene Nachbarzeile Opferzeile (victim row). Kein einziger Zugriff erfolgte je auf die Opferzeile – und trotzdem verändert sich ihr Inhalt.

Die physikalische Ursache ist ein Phänomen, das man treffend als Lesestörung (read disturbance) bezeichnet. Jede Aktivierung einer Zeile erzeugt elektrische Effekte – kapazitive Kopplung zwischen benachbarten Wortleitungen, Leckströme, das Wandern einzelner Elektronen –, die in den Kondensatoren der Nachbarzeile ein winziges bisschen Ladung abziehen oder hinzufügen. Ein einzelnes Klopfen richtet nichts an: Bis zum nächsten Refresh ist die Störung längst ausgeglichen. Aber wenn man Hunderttausende Male hämmert, bevor der rettende Refresh kommt, summieren sich die winzigen Störungen, bis eine Opferzelle über die Schwelle rutscht und ihr Wert von der Hardware falsch interpretiert wird. Das Bit ist gekippt.

Kim und Kollegen erkannten sofort, worauf die Ursache zurückging: Miniaturisierung. Um DRAM immer dichter und billiger zu machen, rücken die Hersteller die Zellen immer enger zusammen. Je kleiner der Abstand zwischen den Zeilen und je weniger Ladung eine geschrumpfte Zelle speichert, desto stärker koppeln benachbarte Zeilen elektrisch aneinander und desto anfälliger wird der Speicher für genau diese Störungen. Rowhammer ist also kein Produktionsfehler einzelner Chargen, sondern eine strukturelle Folge des Fortschritts – der Preis dafür, dass Speicher immer dichter gepackt wird. Ich bin der Meinung, dass gerade dieser Punkt Rowhammer so beunruhigend macht: Die Kraft, die den Speicher verwundbar macht, ist dieselbe, die ihn billig und leistungsfähig macht.

Zum Zeitpunkt der Veröffentlichung war das noch eine Zuverlässigkeits- und Ingenieursfrage – ein „Disturbance Error". Dass daraus binnen eines Jahres eine scharfe Waffe werden würde, ahnte kaum jemand.

Teil 3: Vom Fehler zum Angriff – die Kunst, das richtige Bit zu treffen

Ein zufällig kippendes Bit irgendwo im Speicher ist ein Ärgernis. Ein gezielt kippendes Bit an einer sicherheitskritischen Stelle ist ein Einbruch. Der Schritt von Ersterem zu Letzterem gelang 2015 dem Team von Google Project Zero, namentlich Mark Seaborn und Thomas Dullien. Sie zeigten in einem vielbeachteten Blogbeitrag, dass sich Rowhammer von einem unprivilegierten Programm aus zur vollständigen Übernahme des Systems ausnutzen lässt – und lieferten gleich zwei Exploits.

Der erste brach aus der Sandbox von Google Native Client (NaCl) aus, einer Technik, die untrusted nativen Code sicher im Browser ausführen sollte. Der zweite, der grundsätzlichere, verschaffte einem gewöhnlichen Linux-Prozess Kernel-Rechte und damit Zugriff auf den gesamten physischen Speicher. Damit war der Beweis erbracht: Rowhammer ist kein akademisches Kuriosum, sondern ein Werkzeug zur Rechteausweitung (privilege escalation).

Wie trifft man gezielt das richtige Bit? Drei Zutaten machen den Unterschied.

Erstens das doppelseitige Hämmern (double-sided hammering). Statt nur eine Aggressorzeile zu bearbeiten, hämmert der Angreifer die beiden Zeilen, die eine Opferzeile wie ein Sandwich einschließen – die Zeile darüber und die darunter. Die Störungen aus beiden Richtungen addieren sich, und die Bits in der eingeklemmten Opferzeile kippen weit zuverlässiger und schneller.

Zweitens das Ausräumen des Caches. Damit die Aktivierungen überhaupt bis zum physischen DRAM durchdringen, darf der Prozessor die Zugriffe nicht aus seinem schnellen Cache bedienen. Der Angreifer muss also dafür sorgen, dass jeder Lesezugriff tatsächlich den Speicher erreicht – etwa mit der Instruktion clflush, mit gezieltem Verdrängen des Caches (cache eviction) oder, wenn nichts davon verfügbar ist, mit nicht-zwischengespeichertem Speicher.

Drittens – und das ist die eigentliche Kunst – das Zurechtlegen des Speichers (memory massaging oder memory templating). Ein gekipptes Bit nützt nur, wenn an der Opferstelle etwas Wertvolles liegt. Der Angreifer sucht deshalb zunächst systematisch nach Speicherzellen, die überhaupt zuverlässig kippen (er erstellt eine „Landkarte" der wackligen Bits), und bringt das Betriebssystem dann durch geschicktes Anfordern und Freigeben von Speicher dazu, eine kritische Datenstruktur genau auf eine solche wacklige Zelle zu legen. Der klassische Fall ist ein Page-Table-Entry (PTE) – ein Eintrag in der Seitentabelle, mit der das Betriebssystem virtuelle auf physische Adressen abbildet und Zugriffsrechte verwaltet. Kippt in einem PTE das richtige Bit, so kann der Angreifer eine seiner eigenen Speicherseiten auf eine fremde physische Seite umbiegen – etwa auf eine andere Seitentabelle – und sich damit Schreibzugriff auf den gesamten Speicher verschaffen. Aus einem gekippten Bit wird die Kontrolle über die Maschine.

Eine besonders elegante und beunruhigende Variante lieferten 2020 die Forscher hinter RAMBleed (Andrew Kwong, Daniel Genkin, Daniel Gruss und Yuval Yarom). Ihre Einsicht: Rowhammer muss nicht schreiben, um zu schaden – es kann auch lesen. Ob und wann ein Bit in der Opferzeile kippt, hängt nämlich statistisch vom Wert der Nachbarbits in den Aggressorzeilen ab. Indem RAMBleed beobachtet, welche Bits unter welchen Bedingungen kippen, schließt es rückwärts auf den unbekannten Inhalt fremder Speicherzeilen – ohne diese je zu lesen. Damit extrahierten die Autoren einen geheimen RSA-Schlüssel eines OpenSSH-Servers aus dem Speicher. Rowhammer wurde damit von einem Werkzeug der Integritätsverletzung (Daten verändern) auch zu einem der Vertraulichkeitsverletzung (Daten stehlen).

Teil 4: Der Rüstungswettlauf – jede Verteidigung fiel

Als das Ausmaß klar wurde, reagierte die Industrie mit einer Reihe von Gegenmaßnahmen. Die Geschichte dieser Maßnahmen ist zugleich die Geschichte ihres Scheiterns – ein Wettlauf, bei dem die Verteidiger stets einen Schritt zurücklagen.

Die doppelte Refresh-Rate. Die naheliegendste Idee: Wenn sich die Störungen zwischen zwei Refreshs aufsummieren, dann frischt man eben öfter auf. Viele BIOS-Hersteller halbierten das Refresh-Intervall auf 32 ms. Das erschwert den Angriff, beseitigt ihn aber nicht – schnellere Hämmer-Techniken schaffen die nötigen Aktivierungen auch im halben Fenster. Und häufigeres Auffrischen kostet Strom und Leistung, weil der Speicher währenddessen nicht für Nutzdaten zur Verfügung steht.

Fehlerkorrektur (ECC). Serverspeicher enthält oft ECC (Error-Correcting Code), der ein einzelnes gekipptes Bit pro Speicherwort erkennen und korrigieren kann. Lange galt ECC als weitgehender Schutz. Doch 2018 zeigte die Arbeit ECCploit (Lucian Cojocar und Kollegen von VUSec), dass ECC kein Allheilmittel ist: Kippen zwei oder mehr Bits gleichzeitig, ist ECC überfordert; und über subtile Zeitunterschiede bei der Korrektur lässt sich sogar herausfinden, wo Bits gekippt sind. ECC erhöht die Hürde erheblich, ist aber kein Bollwerk. Der Zusammenhang zur Quantenfehlerkorrektur, die ich an anderer Stelle im Vault beschrieben habe, ist reizvoll: In beiden Welten geht es darum, Information gegen physikalisches Rauschen zu verteidigen – nur ist der „Angreifer" dort die Natur, hier ein Mensch, der das Rauschen gezielt provoziert.

Target Row Refresh (TRR). Die ausgefeilteste Antwort, mit DDR4 in großem Stil eingeführt, ist TRR. Die Idee: Der Speicher (oder der Controller) beobachtet, welche Zeilen ungewöhnlich oft aktiviert werden, erkennt so einen laufenden Angriff und frischt die gefährdeten Nachbarzeilen vorsorglich auf, bevor deren Bits kippen können. TRR wurde als der Durchbruch gefeiert, der Rowhammer endlich erledigt. Die Hersteller erklärten ihre DDR4-Module für „Rowhammer-frei".

Diese Erklärung hielt nicht lange. 2020 zeigte TRRespass (Pietro Frigo und Kollegen von VUSec und ETH Zürich), dass TRR eine entscheidende Schwäche hat: Es kann nur eine begrenzte Anzahl von Aggressorzeilen gleichzeitig im Auge behalten. Ihr Angriff, das vielseitige Hämmern (many-sided hammering), verteilt die Aktivierungen auf viele Aggressorzeilen gleichzeitig und überlastet damit die Zähler des TRR – während es genügend Zeilen unbeobachtet lässt, um Bits zu kippen. TRRespass fand mit einem Fuzzing-Ansatz in vielen der getesteten „geschützten" DDR4-Module wieder verwundbare Muster.

2021 setzte Blacksmith (Patrick Jattke und Kollegen der COMSEC-Gruppe an der ETH Zürich, veröffentlicht auf der IEEE S&P 2022) noch einen drauf. Die Autoren erkannten, dass frühere Angriffe gleichförmig hämmerten – alle Aggressoren mit derselben Frequenz. TRR hatte gelernt, solche Regelmäßigkeit zu erkennen. Blacksmith durchsuchte daher gezielt den Raum nicht-gleichförmiger Muster, bei denen verschiedene Aggressorzeilen mit unterschiedlicher Frequenz, Phase und Amplitude bearbeitet werden – im „Frequenzbereich" gedacht. Ergebnis: Blacksmith kippte Bits auf allen 40 getesteten DDR4-Modulen und entlarvte TRR endgültig als unzureichend.

Zwei weitere Techniken rundeten das Bild ab. Half-Double (Google, 2021) zeigte, dass die Störung nicht nur die direkten Nachbarn erreicht, sondern über eine gekoppelte Zwischenzeile auch die übernächste Zeile – Rowhammer wirkt über größere Distanzen, als man dachte, was viele TRR-Implementierungen aushebelt, die nur die unmittelbaren Nachbarn schützen. Und RowPress (Haocong Luo und Kollegen, ETH Zürich, ISCA 2023) drehte den Angriff um: Statt eine Zeile schnell immer wieder zu öffnen und zu schließen, hält RowPress sie länger geöffnet. Auch das erhöht die Störung der Nachbarn – mit drastisch weniger Aktivierungen, was viele auf Aktivierungszählung basierende Abwehrmechanismen unterläuft.

Das Muster ist unübersehbar: Jede eingesetzte Gegenmaßnahme wurde von der Forschung durchbrochen. Nicht, weil die Ingenieure unfähig gewesen wären, sondern weil die Abwehr bislang reaktiv und heuristisch war – sie erkannte bekannte Angriffsmuster, statt das zugrunde liegende physikalische Problem prinzipiell zu lösen.

Teil 5: Phoenix – der Fall von DDR5 im Jahr 2025

Mit der Speichergeneration DDR5 sollte alles besser werden. Sie bringt eine deutlich ausgefeiltere On-Die-ECC (Fehlerkorrektur direkt im DRAM-Chip) und weiterentwickelte, komplexere TRR-Mechanismen mit. Zunächst schien das zu wirken: ZenHammer (Patrick Jattke und Kollegen, ETH Zürich, USENIX Security 2024) konnte auf AMDs Zen-Plattformen erstmals überhaupt Bits auf einem DDR5-Modul kippen – aber nur bei einem einzigen von zehn getesteten Riegeln. DDR5 galt als harte Nuss.

Diese Hoffnung zerbrach im September 2025 mit Phoenix – erneut aus der COMSEC-Gruppe der ETH Zürich, in Zusammenarbeit mit Google, geführt unter der Kennung CVE-2025-6202 (CVSS 7,1). Phoenix nahm sich die DDR5-Module von SK Hynix vor, dem derzeit größten DRAM-Hersteller der Welt, und legte deren TRR-Schutz durch akribisches Reverse Engineering offen.

Die Forscher rekonstruierten mit FPGA-basierten Experimenten, wann genau der TRR-Mechanismus die aktivierten Zeilen abtastet, um verdächtige Aktivität zu erkennen. Dabei stießen sie auf eine überraschende Struktur: Der Abtastzyklus wiederholt sich nicht, wie bisherige Angriffe annahmen, nach 16, sondern erst nach 128 Refresh-Intervallen (tREFI) – achtmal länger. Und innerhalb dieses langen Zyklus fanden sie blinde Flecken: bestimmte Refresh-Intervalle, in denen der Schutz kaum oder gar nicht abtastet. Genau in diese Lücken legten sie ihre beiden neuen Hämmer-Muster – eines über 128, ein längeres über 2608 Refresh-Intervalle.

Solch lange Muster bergen ein praktisches Problem: Sie umfassen Tausende von Refresh-Operationen, und der Angriff muss über diese ganze Strecke präzise mit dem internen Refresh-Takt des Speichers synchron bleiben. Verliert er den Takt, verpufft die Wirkung. Frühere Synchronisationsverfahren, auch das von ZenHammer, scheiterten an dieser Länge. Phoenix' entscheidende Innovation ist deshalb eine selbstkorrigierende Synchronisation: Statt zu versuchen, jede einzelne Refresh-Operation fehlerfrei zu erkennen, nutzt sie die Periodizität der Refreshs und richtet das Hämmer-Muster automatisch neu aus, sobald sie merkt, dass ein Refresh verpasst wurde. So bleibt der Angriff über Tausende von Intervallen im Takt.

Die Ergebnisse sind ernüchternd. Phoenix kippte Bits auf allen 15 getesteten DDR5-Modulen von SK Hynix (Herstellungsdaten von Ende 2021 bis Ende 2024) – im Schnitt mehrere Tausend gekippte Bits pro Riegel beim kürzeren Muster. Und die Kippungen waren real ausnutzbar: Die Autoren demonstrierten drei praktische Angriffe – das Manipulieren von Page-Table-Entries für beliebigen Lese-/Schreibzugriff (alle Module verwundbar), das Stehlen eines RSA-2048-Schlüssels einer mitbewohnten virtuellen Maschine zum Brechen der SSH-Authentifizierung (73 % der verwundbaren Module) und das Manipulieren der sudo-Binärdatei zur lokalen Rechteausweitung auf root (33 %). Auf einem handelsüblichen PC mit Standardeinstellungen gelang die vollständige Übernahme mit root-Rechten in so wenig wie 109 Sekunden.

Zwei Details verdienen besondere Beachtung. Erstens: On-Die-ECC hält Phoenix nicht auf. Der Chip-interne Fehlerkorrektur korrigiert Bits nur beim Schreiben oder in großen zeitlichen Abständen – hämmert man einfach lange genug, häufen sich Fehler schneller an, als ECC sie beseitigt. Zweitens: Der einzige zuverlässige Schutz, den die Forscher für bestehende Module fanden, ist die alte Idee in verschärfter Form – die Refresh-Rate verdreifachen (tREFI ≈ 1,3 µs), was Phoenix in ihren Tests stoppte, aber rund 8,4 % Leistungseinbuße kostet. Die Autoren legten Phoenix ordentlich offen: Sie meldeten den Fund am 6. Juni 2025 über das Schweizer NCSC an SK Hynix, die CPU-Hersteller und große Cloud-Anbieter; der Embargo lief bis zum 15. September 2025. Die vollständige Veröffentlichung erscheint auf der IEEE S&P 2026.

Teil 6: Warum das Problem nicht verschwindet

Zwölf Jahre nach Kims Entdeckung ist Rowhammer nicht gelöst, sondern schlimmer geworden. Das hat einen tiefen, unbequemen Grund: Die Ursache ist Physik, und die Physik zieht in die falsche Richtung. Jede neue Speichergeneration packt die Zellen dichter, verkleinert die Strukturen und speichert weniger Ladung pro Bit – und jeder dieser Schritte, die den Speicher billiger und schneller machen, verschärft die Kopplung zwischen den Zeilen und damit die Anfälligkeit. Rowhammer ist der Schatten der Miniaturisierung.

Erschwerend kommt ein wirtschaftlicher und struktureller Faktor hinzu: Der eingebaute Schutz sitzt im DRAM-Chip und lässt sich nach der Auslieferung nicht mehr aktualisieren. Eine Software-Lücke patcht man in Stunden; einen verwundbaren Speicherriegel kann man nur austauschen. Milliarden bereits verbauter Module werden ihre Schwäche über ihre gesamte Lebensdauer behalten. Und weil die bisherigen Gegenmaßnahmen heuristisch sind – sie erkennen bekannte Muster, statt das Problem an der Wurzel zu lösen –, war jede von ihnen im Nachhinein umgehbar.

Was hilft dann? Ein Bündel von Ansätzen, keiner davon allein ausreichend:

Prinzipielle Zähler statt Heuristik. Die vielversprechendste Richtung sind DRAM-interne Mechanismen, die jede häufig aktivierte Zeile zuverlässig zählen und schützen, statt zu raten – etwa der von JEDEC für DDR5 spezifizierte Ansatz PRAC (Per Row Activation Counting), der jeder Zeile einen echten Aktivierungszähler gibt. Ich bin der Meinung, dass nur solche prinzipiellen, nicht auf Mustererkennung beruhenden Verfahren den Wettlauf langfristig gewinnen können – alles andere lädt den nächsten cleveren Angriff geradezu ein.

Erhöhte Refresh-Rate. Wie bei Phoenix gesehen: teuer erkauft, aber wirksam. Ein Notbehelf für bestehende Hardware, kein Dauerzustand.

Softwareseitige Isolation. Auf Systemebene kann man den Schaden begrenzen, indem man kritische Datenstrukturen physisch von unprivilegiertem Speicher trennt (guard rows, domänenbewusste Speicherzuteilung), sodass ein Angreifer gar nicht erst in die Nähe lohnender Opferzeilen gelangt. Das behebt Rowhammer nicht, verteuert aber die Ausnutzung.

Bewusstsein im Bedrohungsmodell. Für Cloud-Betreiber – und damit für Svens tägliche Arbeit – ist die wichtigste Lehre: In einer mehrmandantenfähigen Umgebung teilen sich fremde Arbeitslasten dieselben physischen Speicherchips. Phoenix hat gezeigt, dass ein Angreifer aus einer virtuellen Maschine den RSA-Schlüssel einer anderen VM auf demselben Wirt stehlen kann. Die Isolation zwischen Mandanten, die man gern als gegeben annimmt, endet nicht an der Softwaregrenze der Virtualisierung, sondern reicht bis in die Physik der Speicherzelle hinunter.

Ein Zeitstrahl des Wettlaufs

Erkenntnis zum Mitnehmen

Der praktische Kern dieses Artikels lässt sich in einem einzigen, unbequemen Satz verdichten: Sicherheit endet nicht an der Softwaregrenze – sie reicht bis in die Physik der Hardware hinab. Rowhammer ist die Erinnerung daran, dass unsere gesamte Sicherheitsarchitektur auf einer stillschweigenden Annahme ruht, die falsch ist: dass ein Speicherzugriff nur die adressierte Zelle betrifft. Wo diese Annahme kippt, kippen die Bits.

Für Svens Arbeit – in der Cloud-Architektur, im Sicherheitsdesign, beim Betrieb von Systemen mit sensiblen Daten – ist die übertragbare Lektion zweifach. Erstens: Prüfe dein Bedrohungsmodell auf physische Annahmen. Wenn du fremde Arbeitslasten auf gemeinsamer Hardware betreibst, ist die Isolation zwischen ihnen nur so stark wie die schwächste physikalische Kopplung im System – und die liegt außerhalb dessen, was ein Software-Patch je erreichen kann. Für hochsensible Schlüssel und Geheimnisse ist dedizierte Hardware, ein HSM oder erhöhte Speicher-Härtung keine Paranoia, sondern eine berechtigte Antwort auf eine bewiesene Angriffsklasse. Zweitens, allgemeiner: Miss der Reaktion heuristischer Abwehr mit Skepsis. Die zwölfjährige Geschichte von Rowhammer ist eine einzige Lehrstunde darüber, dass Verteidigungen, die bekannte Muster erkennen, statt das zugrunde liegende Problem prinzipiell zu lösen, im Nachhinein fast immer umgangen werden. Diese Faustregel gilt weit über den Speicher hinaus – für Intrusion Detection, für Spam-Filter, für jede Abwehr, die auf Signaturen statt auf Invarianten setzt.

Reflexionsfrage

Rowhammer nutzt aus, dass eine physikalische Nebenwirkung eine logische Grenze durchbricht, die wir für absolut hielten. Wo in deinen eigenen Systemen verlässt du dich implizit auf eine „Isolation", die in Wahrheit nur eine bequeme Annahme ist – geteilter Speicher, geteilte CPU-Caches, geteilte Netzwerkpfade, geteilte physische Hardware –, und was würde deine Architektur ändern, wenn du davon ausgingest, dass jede geteilte Ressource ein potenzieller Seitenkanal ist?

Querverweise im Vault

• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – die verwandte Familie der mikroarchitektonischen Angriffe: dort verrät die spekulative Ausführung Geheimnisse über einen Cache-Seitenkanal, hier durchbricht eine physikalische Störung die Speicherisolation. Beide zeigen, wie Hardware-Optimierungen zu Sicherheitslücken werden.
• Ordnung aus dem Rauschen: Quantenfehlerkorrektur und der Weg zum fehlertoleranten Quantencomputer – Fehlerkorrektur als Verteidigung von Information gegen physikalisches Rauschen; bei Rowhammer wird das Rauschen von einem Angreifer gezielt provoziert und ECC bewusst ausgehebelt.
• Der Schlüssel, der nach jeder Nachricht stirbt: Das Signal-Protokoll, die Double Ratchet und die Kunst der Ende-zu-Ende-Verschlüsselung – die stärkste Kryptografie nützt nichts, wenn der Schlüssel im Klartext im Speicher liegt und dort – wie bei RAMBleed und Phoenix demonstriert – herausgehämmert werden kann. Der Endpunkt als Schwachstelle.
• Die Wette auf fremden Code: Firecracker microVMs und das Ende des Container-VM-Dilemmas – Mandantenisolation in der Cloud: Firecracker härtet die Softwaregrenze, doch Phoenix zeigt, dass die physische Speicherkopplung darunter eine eigene Angriffsfläche bleibt.

Quellen

• Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, O. Mutlu: Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors, ISCA 2014. https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
• M. Seaborn, T. Dullien: Exploiting the DRAM rowhammer bug to gain kernel privileges, Google Project Zero, 2015. https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
• P. Frigo, E. Vannacci, H. Hassan, V. van der Veen, O. Mutlu, C. Giuffrida, H. Bos, K. Razavi: TRRespass: Exploiting the Many Sides of Target Row Refresh, IEEE S&P 2020. https://download.vusec.net/papers/trrespass_sp20.pdf
• P. Jattke, V. van der Veen, P. Frigo, S. Gunter, K. Razavi: BLACKSMITH: Scalable Rowhammering in the Frequency Domain, IEEE S&P 2022. https://comsec.ethz.ch/wp-content/files/blacksmith_sp22.pdf
• H. Luo, A. Olgun, A. G. Yağlıkçı, Y. C. Tuğrul, S. Rhyner, M. B. Cavlak, J. Lindegger, M. Sadrosadati, O. Mutlu: RowPress: Amplifying Read Disturbance in Modern DRAM Chips, ISCA 2023. https://arxiv.org/abs/2306.17061
• A. Kwong, D. Genkin, D. Gruss, Y. Yarom: RAMBleed: Reading Bits in Memory Without Accessing Them, IEEE S&P 2020. https://rambleed.com/
• ETH Zürich COMSEC & Google: Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization (CVE-2025-6202), IEEE S&P 2026. https://comsec.ethz.ch/research/dram/phoenix/
• O. Mutlu, J. S. Kim: RowHammer: A Retrospective, IEEE TCAD 2019. https://arxiv.org/abs/1904.09724

Hinweis: Dieser Artikel gibt den überprüfbaren, wissenschaftlich gesicherten Stand wieder. Wo eigene Einschätzungen einfließen, sind sie mit „Ich bin der Meinung, dass ..." gekennzeichnet.

← All articles