Software::Security

»Row Hammer«: Speicherphänomene führen zu Sicherheitslücken

Ein als »Row Hammer« bei DRAM-Herstellern bekanntes Phänomen lässt sich unter Umständen dazu nutzen, ein System zu kompromittieren und beispielsweise unter Linux an Root-Rechte zu kommen. Betroffen von dem Problem sind etliche Chips und Systeme.

Die Isolation von Speicherbereichen ist eine der wichtigsten und effektivsten Mechanismen, um die Sicherheit eines Systems zu erhöhen. Demnach erfolgt ein Zugriff auf eine bestimmte Adresse eines Speicherbereiches isoliert und hat theoretisch keine Auswirkungen auf andere Bereiche des Speichers. Mit immer kleineren Chips wurde es allerdings für die Hersteller immer schwieriger, benachbarte Zellen eines DRAMs auch komplett zu isolieren. So kann es unter Umständen dazu kommen, dass das Beschreiben einer Zelle zu unerwünschten Nebenwirkungen führt und den Zustand einer Nebenzelle verändern kann. Salopp gesagt, »kippt« der Zustand der benachbarten Zelle und beinhaltet Informationen, die unter Umständen zu Angriffen genutzt werden könnten.

Das Problem selbst ist nicht neu. Bereits 2014 beschrieben Forscher der Carnegie Mellon University und der Intel Labs das Verhalten unter dem Titel »Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors«. Die Beobachtung der Forscher brachte zutage, dass das stetige Beschreiben einer Zelle im Zuge eines Standard-Integritätstests (Hammer-Test) zu unerwünschten Resultaten führen kann. So hat ein unbenannter Ausrüster beobachtet, dass im Zuge der Inbetriebnahme bei DDR4 DRAMs das Beschreiben einer Speicherzelle den Zustand der benachbarten Zelle verändern konnte. Das Verhalten selbst wurde »Row Hammer« benannt.

Dass es sich bei dem Phänomen nicht nur um ein theoretisches Problem handelt, beweisen nun Mark Seaborn, Matthew Dempsky und Thomas Dullien durch praktische Experimente. Den Entwicklern ist es laut eigener Aussage gelungen, das Verhalten der Chips in die Form eines Exploits zu gießen, der es den Forschern ermöglichte, unter Linux sich unter anderem unautorisiert Root-Rechte zu verschaffen.

Um das Vorhaben auch realisieren zu können, bedarf es allerdings nicht geringer Anstrengungen und Know-hows. Grund hierfür sind das physikalische Address-Mapping und die virtuelle Speicherverwaltung. So ist es unter anderem nicht sichergestellt, dass durch das Reservieren eines Speichers zwei nebeneinanderliegende Zellen belegt werden. Unter Linux kann der Anwender zwar mit Hilfe von beispielsweise Proc-Einträgen das Mapping zwischen dem physikalischen und dem virtuellen Speicher herausfinden, doch ohne eine genaue Kenntnis des verwendeten Speicher-Kontrollers lässt sich die Zuordnung nur bedingt zuverlässig berechnen. Auch das »Hämmern« selbst ist nicht trivial, hängt vom System ab und betrifft nicht alle Systeme, weshalb die Entwickler ihre Ergebnisse virtualisiert aufarbeiten.

Denn nachdem die Entwickler die geeigneten Systeme und Methoden herausfanden, waren sie in der Lage, das laufende System zu manipulieren und beispielsweise aus einer laufenden NaCl-Sandbox auszubrechen. NaCl ist eine Sandbox-Technologie, die es ermöglicht, hochperformante C- oder C++-Anwendungen in einer Browserumgebung auszuführen. Die Technologie wurde von Google unter den Bedingungen der BSD-Lizenz veröffentlicht und wird nur von Google selbst eingesetzt. Da bei NaCl der Maschinencode vor dem Ausführen geprüft wird, um beispielsweise einen Ausbruch zu verhindern, gilt die Lösung als durchaus sicher. »Row Hammer« führt allerdings dazu, dass der Code nach der Überprüfung im Speicher verändert wird, was jegliche Sicherheitsmechanismen des Systems aushebelt.

Mirko Lindner rowhammer_test in Aktion

Dasselbe gilt auch für das zweite Angriffszenario, das die Forscher vorgestellt haben. Hier ist es ihnen gelungen, unter Linux die Privilegienüberprüfung auszuhebeln. Dazu verändern sie den Page-Table-Einsprungspunkt (PTE), sodass er auf eine physikalische Adresse und die Page-Table des angreifenden Prozesses zeigt. Wie das genau funktioniert, beschreiben die Entwickler in ihrem Blog-Eintrag

Wie die Entwickler schrieben, handelt es sich bei allen »Row Hammer«-Angriffen um praktische Experimente, die nicht auf allen Systemen funktionieren. Von den insgesamt 29 getesteten Systemen war knapp die Hälfte (15) von dem Problem betroffen, wobei oftmals die Kombination von der genutzten CPU und dem Speicher sowie der Zeiteinsatz ausschlaggebend waren. Anwender, die testen wollen, ob ihr System gegen einen »Row Hammer«-Angriff sicher ist, finden eine Testanwendung im Git-Repositorium der Entwickler.

Auch wenn das Problem nun technisch greifbar ist, Grund zur Panik gibt es noch nicht. Denn das Problem der »kippenden« Bits ist nicht neu. Bereits 2003 haben Sudhakar Govindavajhala und Andrew W. Appel von der Princeton University in ihrem Whitepaper »Using Memory Errors to Attack a Virtual Machine« gezeigt, wie Bitfehler für Ausbrüche oder Angriffe genutzt werden können. Es ist zudem davon auszugehen, dass auch die Entwickler von Sicherheitssystemen sich der Problematik annehmen werden. Doch auch die Hardware-Produzenten wissen um das Problem und korrigieren beispielsweise durch bessere Tests oder BIOS-Einstellung oder Schranken die Zugriffe, wie die Forscher schreiben. Unklar ist zudem, welche Technologien von dem Problem wirklich betroffen sind und ob beispielsweise ECC-Speicher das Problem beheben würde.

Fest steht deshalb, dass die praktische Nutzung der »Row Hammer«-Problematik zu weiteren Reaktionen führen wird. Denn auch wenn die Problematik noch nicht praktisch für Angriffe genutzt wird, hat die Zeit gezeigt, dass solche Angriffe kommen werden. Gründe hierfür gebe es genug. Einer davon wäre zum Beispiel, um aus einer Abstraktionsschicht auszubrechen. Die Forscher fordern deshalb die Hardware-Hersteller auf, sich genauso wie die Software-Branche der Problematik der Sicherheitsaspekte bewusst zu werden und sich Diskussionen nicht zu verwehren. »Solche Diskussionen werden zu sicherer Hardware führen, von der alle Nutzer profitieren werden«, so das abschließende Fazit der Forscher.