Rowhammer
Rowhammer bezeichnet einen Konstruktionsfehler bei Speicherbausteinen, bei denen sich bestimmte Bits im Arbeitsspeicher (DRAM) ohne Schreibzugriff auf diese verändern lassen. Dieser Fehler ermöglicht es einem Angreifer in der Theorie, durch derartige Veränderungen bestimmter Bits z. B. Sicherheitsvorkehrungen zu umgehen. Der erste auf diesem Effekt basierende praktische Angriff wurde im März 2015 durch Mark Seaborn, Matthew Dempsky und Thomas Dullien einer breiten Öffentlichkeit bekannt. Mark Seaborn gelang nach eigenen Angaben das Ausnutzen der Schwachstelle auf 15 von 29 Laptops.[1]
Funktionsweise
Der Arbeitsspeicher ist physisch in Reihen organisiert. Um auf Speicher zuzugreifen, wird der Speicher aus einer solchen Reihe in einen Puffer kopiert, auf den man dann zugreifen kann. Erst wenn auf eine andere Reihe zugegriffen werden soll, wird diese Reihe zurückgeschrieben und die andere Reihe in den Reihenpuffer geladen. Wird mit hoher Frequenz auf eine Speicheradresse (im Wechsel mit einer anderen Adresse) zugegriffen, muss der Arbeitsspeicher die Reihen ebenso häufig lesen und zurückschreiben. Hierbei interagieren die elektrischen Felder der Reihen, auf die ein Angreifer Zugriff hat, mit benachbarten Reihen des Arbeitsspeichers. Die Ladung „leckt“ dann, was zur Änderung eines benachbarten Bits führen kann. Das führt zu Fehlfunktionen des Computers, wie etwa dem Abstürzen von Programmen oder des Betriebssystems, Datenverfälschung oder – bei gezielter Ausnutzung – zu unerlaubtem Zugriff auf den gesamten Rechner.[2][3]
Im Normalbetrieb ist das Auftreten des Rowhammer-Effekts unwahrscheinlich, da Speicherzugriffe vom Cache gepuffert werden und daher nicht in dieser Frequenz auftreten. Der Prozessor bietet allerdings mit dem Clflush-Befehl die Möglichkeit, gezielt Speicher aus dem Cache zu werfen. Wird dieser Befehl gezielt ausgenutzt, muss der Arbeitsspeicher tatsächlich ebenso häufig Reihen lesen und zurückschreiben.[3]
Ein von Mark Seaborn geschriebenes Programm demonstriert, dass der Rowhammer-Effekt tatsächlich eine Sicherheitslücke darstellt. Es schreibt so lange auf bestimmte Bereiche des Arbeitsspeichers, bis ein Bit, für welches das laufende Programm keinen Schreibzugriff besaß, verändert wurde.[4] Seaborns Programm beruht auf den Vorarbeiten einer Arbeitsgruppe der Carnegie Mellon University und von Intel Labs.[3]
Praktische Anwendung
Da die RAM-Kompromittierung nicht an spezielle Programme gebunden ist, ist eine Vielzahl an Angriffen möglich. Von Seaborn erprobt ist ein Angriff auf die NaCl-Sandbox im Webbrowser Chrome und das Erlangen von Root-Rechten unter Linux. Im Juli 2015 gelang es dem Forscherteam Gruss, Maurice und Mangard auch über JavaScript, einen Angriff auf ein System durchzuführen. Seaborn selbst nimmt an, dass nicht nur Linux von dem Problem betroffen ist. Theoretisch möglich ist auch der Ausbruch aus einer virtuellen Maschine. Dieser Angriff ist noch nicht praktisch erprobt, dürfte aber auf Servern ohne (fehlerkorrigierende) ECC-Speicher (siehe Abwehrmethoden) möglich sein.[2] Im November 2018 zeigte das Forscherteam Cojocar, Razavi, Giuffrida, Bos von der Vrije Universiteit Amsterdam, dass auch ECC-Speicher nicht vor (modifizierten) Rowhammer-Angriffen sicher sind.[5]
NaCl
Die NaCl-Sandbox prüft vor dem Ausführen den Maschinencode auf gefährliche Aufrufe. Hierdurch soll der Ausbruch aus der Sandbox verhindert werden, wodurch die Sandbox bisher als sicher galt. Durch Rowhammer kann der Code nach der Überprüfung manipuliert werden, durch permanentes Aufrufen des Clflush-Befehls wird verhindert, dass der Speicherzugriff zwischengespeichert (“cached”) wird. Neuere Versionen von NaCl erlauben daher den Aufruf von Clflush nicht mehr. Die in früheren Versionen fehlende Filterung wird als Sicherheitslücke CVE-2015-0565[6] geführt. Seitens Seaborn werden zurzeit weitere Angriffe ohne Clflush diskutiert, praktisch umgesetzt wurde davon jedoch keiner. Aus diesem Grund plädiert Seaborn dafür, Nutzern die Ausführung des Clflush-Befehls zu verbieten. Außerhalb des Kernels gebe es nur wenige Gründe, den Befehl aufzurufen.[1][7]
Root-Rechte
Hierfür wird versucht, mit Hilfe von Bit-Veränderungen Kontrolle über eine Page Table des eigenen Prozess zu erhalten. Dadurch könnte ein Angreifer sämtlichen physischen Speicher auslesen und verändern.[8]
JavaScript
Im Juli 2015 gelang es Gruss, Maurice und Mangard über JavaScript, den Rowhammer-Effekt auszulösen. Der Angriff basiert nicht darauf, spezielle JavaScript-Funktionen auszunutzen, sondern darauf, den Clflush-Befehl durch gezielte Speicherzugriffe zu simulieren. Es ist wahrscheinlich, dass sich die gleiche Vorgehensweise auch auf andere Sprachen übertragen lässt. Die Forscher bewiesen lediglich, dass der Angriff im Webbrowser Mozilla Firefox möglich ist, jedoch ist es auch hier wahrscheinlich, dass der Angriff in anderen Webbrowsern auf ähnliche Weise möglich ist.[9][10] Die Implementation des Angriffs wurde mittlerweile auf GitHub veröffentlicht.[11]
Abwehrmethoden
Da diese Sicherheitslücke Eigenheiten der Hardware ausnutzt, ist eine Behebung nicht durch einfache Softwarelösungen wie etwa den Wechsel des Virenscanners oder des Betriebssystems möglich. Einen teilweisen Schutz vor einem Rowhammer-Angriff bietet fehlerkorrigierender RAM, wie etwa die Verwendung von ECC-Speichermodulen.[2] Hierfür ist es jedoch notwendig, dass entweder der Arbeitsspeicher selbständig die Korrekturen vornimmt, oder der ECC-fähige RAM mit einer ECC-fähigen CPU kombiniert wird. Hierdurch wird jedoch nur ein Schutz gegen das Umkippen einzelner Bits, nicht jedoch gegen das Umkippen mehrerer auf einmal, geleistet. Neue Untersuchungen jedoch zeigen, dass auch ECC-fähiger RAM gegen Rowhammer-Attacken verwundbar ist.[12]
Vorzeitige Sicherheit bietet der u. a. PaX umfassende GrSecurity-Patch für den Linux-Kernel, da Zugriffe auf die “page maps” von Benutzerprozessen blockiert werden. Wirkliche Sicherheit bietet der Patch jedoch nicht. Zur Erschwerung des Angriffs wurde mit dem Linux-Kernel 4.0 der Zugriff auf das Verzeichnis /proc erschwert.[9]
In einem Fall konnte Seaborn eine Herauszögerung des Angriffs durch ein überarbeitetes BIOS bewirken. Statt einiger Minuten brauchte der Forscher nun 40 Minuten für den Angriff. Ein wirksamer Schutz ist diese Methode damit jedoch nicht.[7]
2014 wurde das Target Row Refresh (TRR) für Memory Controller eingeführt. Aber 2020 konnten Forscher zeigen, dass dieser Schutz nicht ausreichend ist (CVE-2020-10255 bei MITRE (englisch)).[13]
Literatur
Einzelnachweise
- Mirko Lindner: »Row Hammer«: Speicherphänomene führen zu Sicherheitslücken. In: pro-linux.de. 10. März 2015, abgerufen am 14. März 2015.
- Hanno Böck: Angriff der Bitschubser. In: ZEIT online. 10. März 2015, abgerufen am 14. März 2015.
- Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, Onur Mutlu: Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors. (PDF) Abgerufen am 14. März 2015 (englisch).
- Program for testing for the DRAM „rowhammer“ problem. In: GitHub. Abgerufen am 14. März 2015 (englisch).
- Lucian Cojocar, Kaveh Razavi, Cristiano Giuffrida, Herbert Bos: Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks. 22. November 2018 (vu.nl [PDF]).
- CVE-2015-0565 bei MITRE (englisch)
- Hanno Böck: RAM-Chips geben Angreifern Root-Rechte. In: Golem.de. 10. März 2015, abgerufen am 14. März 2015.
- Eine detaillierte Anleitung für den Angriff ist hier verfügbar
- Hanno Böck: Rowhammer: Speicherbitflips mittels Javascript. In: Golem.de. 28. Juli 2015, abgerufen am 30. Juli 2015.
- Daniel Gruss, Clémentine Maurice, Stefan Mangard: Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript. 27. Juli 2015, arxiv:1507.06955.
- Daniel Gruss, Clémentine Maurice: IAIK/rowhammerjs: rowhammerjs/rowhammer.js at master. In: github.com. 27. Juli 2015. Abgerufen am 29. Juli 2015.
- Lucian Cojocar, Kaveh Razavi, Cristiano Giuffrida, Herbert Bos: Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks. (PDF) Abgerufen am 3. Dezember 2018 (englisch).
- Is it still possible to run malware in a browser using JavaScript and Rowhammer? Yes, yes it is (slowly)