Rowhammer wird derzeit viel in den Medien diskutiert. Auch unser Forschungsteam bei Oneconsult hat dieses neuentdeckte Problem aufgegriffen und analysiert – dabei sind wir bei ersten eigenen Untersuchungen zu interessanten Ergebnissen gekommen.
Worum geht es? Bei allen gängigen DRAM-Speicher-Modulen sind die einzelnen Speicherzellen als Matrix auf der Silizium-Oberfläche der Chips angeordnet. Die in den Zellen verwendete Art der (Ladungs-) Speicherung ist stark flüchtig und muss daher alle paar 10 Millisekunden erneuert werden (daher das D für „Dynamic“ im Namen). Bei Lese- und Schreiboperationen werden immer ganze Zeilen von Zellen bearbeitet und dabei entsprechend auch mit neuer oder anderer Ladung belegt. Beide Operationen führen zu elektrischen Feldern und Ladungen, die die Entladung oder Ladung von Zellen in benachbarten Zeilen beeinflussen können. Dieser Effekt ist schon länger bekannt, wurde jedoch bisher nur als Problem bei der Zuverlässigkeit gesehen.
Die jetzt veröffentlichten Ergebnisse beweisen, dass dieser Effekt auch (mehr oder weniger) gezielt ausgenutzt werden kann, um Veränderungen in normalerweise nicht zugänglichen (oder zumindest nicht schreibbaren) Bereichen auszulösen und damit auch Schutzmassnahmen umgangen werden können.
Auch wenn die präsentierten Ergebnisse nur Linux betreffen (wo von einem normalen Benutzer-Prozess aus vollständiger System-Zugriff erlangt werden konnte), gibt es keinen technischen Grund warum derartige Angriffe nicht auch bei anderen Betriebssystemen oder auch zum Ausbruch aus Hardware-Virtualisierungs-Umgebungen verwendet werden könnten. Es ist zwar noch unklar, in wieweit die Ergebnisse auf unterschiedliche Systeme und Situationen übertragbar sind, aber Angriffe werden immer nur besser. Die Entwicklung in diesem Bereich sollte also genau beobachtet werden, insbesondere da Schutzmassnahmen sehr schwierig und teilweise nur über Firmware- oder gar Hardware-Änderungen möglich sind.
Es gibt zwar Ansätze und Möglichkeiten um die konkret beschriebenen Angriffe zu erschweren oder zu erkennen, aber auch diese müssen auf Betriebssystem-Ebene implementiert werden, sodass eine flächendeckende Verbreitung dieser Massnahmen noch einige Zeit auf sich warten lassen dürfte.
Systeme mit ECC-RAM, die ja genau zufällige Speicherveränderungen verhindern sollen, sind sicher deutlich weniger anfällig für diesen Angriff, aber da dabei nur wenige Bits pro 64-Bit Wort geschützt werden können und bei unseren Tests bis zu 89 Fehler in einem 4KiB Abschnitt auftraten ist fraglich, ob diese Fehlerschwelle nicht, mindestens in Einzelfällen, überschritten werden kann.
Bei unseren eigenen Tests mit den verfügbaren Tools (rowhammer_test und memtest86) sind uns zwei Punkte aufgefallen, die bisher noch kaum wahrgenommen und unserer Meinung nach nicht angemessen in der bisherigen Berichterstattung berücksichtigt wurden:
- Die bisher an den meisten Stellen empfohlenen Testmethoden sind unvollständig.
Die überwiegend verwendeten Tools „rowhammer_test“ und „memtest86“ (Test 13) verwenden nur einseitiges Rowhammering, dabei wurde bereits im ursprünglichen Blog-Eintrag erwähnt, dass beidseitiges (engl. „Double Sided“ – also Verwendung der Speicher Zeilen ober- und unterhalb der Ziel-Zeile) Rowhammering zusätzliche Fehlerstellen produzieren kann. So konnte mit dieser Methode bei einem unserer Test-Geräte, das bei den einseitigen Tests unauffällig war, Speicher-Fehler provoziert werden.
Das Tool „double_sided_rowhammer“ wird inzwischen auch mit dem mitgelieferten Make-Skript kompiliert und sollte auch für Tests verwendet werden. Es ist zwar noch nicht ganz ausgereift und kann auch noch keine vollständige Garantie bieten, dass der Fehler auf einem System nicht auftreten kann, aber die Zuverlässigkeit sollte doch deutlich steigen.
- Die Temperatur der RAM-Module ist relevant.
Auch dieser Effekt ist bekannt und wurde auch in umgekehrter Form schon für die sogenannten „Cold-Boot“-Angriffe ausgenutzt.
In Kürze: Je höher die Temperatur, desto stärker und schneller sind die Ladungsverschiebungen in den DRAM-Zellen.
Wir konnten Bit-Veränderungen beobachten, die nur bei höheren System-Temperaturen auftraten und nach einer Abkühlung des Systems wieder verschwanden. Wir verwendeten zur Erhöhung der Temperatur CPU-Benchmarks, es ist jedoch auch denkbar, das RAM durch Rowhammering oder andere spezielle Zugriffsmuster gezielt aufzuheizen und so zusätzliche Fehler zu produzieren.
Zusammenfassend kann festgehalten werden, dass wie bei vielen neu entdeckten Sicherheitsproblemen, das genaue Ausmass noch nicht genau festgestellt werden kann und es noch einigen Klärungsbedarf gibt.
Die gefährdetsten Systeme sind aktuell solche mit x86-Architektur ohne ECC-RAM, auf denen unkontrollierte Software (mit x86/x86_64 Instruktionen – auch in Sandboxen) von Dritten oder Personen mit eingeschränkten Berechtigungen ausgeführt werden kann.
Allerdings kann aktuell, ausser einem Wechsel auf ECC-fähige Hardware mit ECC-RAM-Modulen, noch keine zuverlässige Methode zur Reduzierung des Risikos empfohlen werden. Bei gefährdeten Systemen kann jedoch durch die verfügbaren Tools eine erste Einschätzung erlangt werden, ob das System mehr oder weniger anfällig ist (wobei darauf geachtet werden sollte, die Tools nicht im normalen Betrieb einzusetzen, da im schlimmsten Fall beliebige Stellen im Speicher geändert werden könnten).
Das Forschungsteam der Oneconsult wird das Thema weiter beobachten und wenn immer möglich auch aktiv zu einer Lösung beitragen.
[Update folgt]
