
Proof-of-Concept-Demos und die libkdump-Bibliothek, die den mikroarchitektonischen Meltdown-Angriff demonstrieren und Kernel- sowie physischen Speicher auf anfälligen Intel-CPUs auslesen.
Dieses Repository enthält mehrere Anwendungen, die den Meltdown-Bug demonstrieren. Für technische Informationen über den Bug siehe das Paper:
Die Anwendungen in diesem Repository wurden mit libkdump erstellt, einer Bibliothek, die wir für das Paper entwickelt haben. Diese Bibliothek vereinfacht die Ausnutzung des Bugs, indem sie sich automatisch an bestimmte Eigenschaften der Umgebung anpasst.
Dieses Repository enthält mehrere Videos, die Meltdown demonstrieren
Dieses Repository enthält fünf Demos, um verschiedene Anwendungsfälle zu demonstrieren. Alle Demos wurden auf Ubuntu 16.04 mit einem Intel Core i7-6700K getestet, aber sie sollten auf jedem Linux-System mit jeder modernen Intel-CPU seit 2010 funktionieren.
Für beste Ergebnisse empfehlen wir eine schnelle CPU, die Intel TSX unterstützt (z. B. jeder Intel Core i7-5xxx, i7-6xxx oder i7-7xxx). Darüber hinaus sollte jede Demo an einen CPU-Kern gebunden werden, z. B. mit taskset.
Als Voraussetzung müssen Sie glibc-static auf Ihrem System installieren.
Für RPM-basierte Systeme:
sudo yum install -y glibc-static
test)Dies ist die einfachste Demo. Sie verwendet Meltdown, um zugängliche Adressen aus dem eigenen Adressraum zu lesen, ohne Isolationsmechanismen zu durchbrechen.
Wenn diese Demo bei Ihnen nicht funktioniert, werden die übrigen Demos höchstwahrscheinlich ebenfalls nicht funktionieren. Die Gründe sind vielfältig, z. B. könnte die CPU zu langsam sein, keine Out-of-Order-Ausführung unterstützen, der hochauflösende Timer nicht präzise genug sein (insbesondere in VMs), das Betriebssystem keine benutzerdefinierten Signal-Handler unterstützen usw.
make
taskset 0x1 ./test
Wenn Sie eine Ausgabe ähnlich dieser sehen
Expect: Welcome to the wonderful world of microarchitectural attacks
Got: Welcome to the wonderful world of microarchitectural attacks
dann funktioniert die Basis-Demo.
kaslr)Ab dem Linux-Kernel 4.12 ist KASLR (Kernel Address Space Layout Randomization) standardmäßig aktiv. Das bedeutet, dass sich die Position des Kernels (und auch die direkte physische Map, die den gesamten physischen Speicher abbildet) bei jedem Neustart ändert.
Diese Demo verwendet Meltdown, um die (geheime) Randomisierung der direkten physischen Map preiszugeben. Diese Demo erfordert Root-Rechte, um den Prozess zu beschleunigen. Das Paper beschreibt eine Variante, die keine Root-Rechte erfordert.
make
sudo taskset 0x1 ./kaslr
Nach einigen Sekunden sollten Sie etwas Ähnliches wie dies sehen
[+] Direct physical map offset: 0xffff880000000000
reliability)Diese Demo testet, wie zuverlässig physischer Speicher gelesen werden kann. Für diese Demo benötigen Sie entweder den Offset der direkten physischen Map (z. B. aus Demo #2) oder Sie müssen KASLR deaktivieren, indem Sie nokaslr in Ihrer Kernel-Kommandozeile angeben.
Erstellen und starten Sie reliability. Wenn KASLR aktiviert ist, ist der erste Parameter der Offset der direkten physischen Map. Andernfalls benötigt das Programm keinen Parameter.
make
sudo taskset 0x1 ./reliability 0xffff880000000000
Nach einigen Sekunden sollten Sie eine Ausgabe ähnlich dieser erhalten:
[-] Success rate: 99.93% (read 1354 values)
physical_reader)Diese Demo liest Speicher aus einem anderen Prozess, indem sie direkt physischen Speicher liest. Für diese Demo benötigen Sie entweder den Offset der direkten physischen Map (z. B. aus Demo #2) oder Sie müssen KASLR deaktivieren, indem Sie nokaslr in Ihrer Kernel-Kommandozeile angeben.
Im Prinzip kann dieses Programm beliebige physische Adressen lesen. Da der physische Speicher jedoch viele nicht menschenlesbare Daten enthält, stellen wir ein Testwerkzeug (secret) bereit, das eine menschenlesbare Zeichenkette in den Speicher schreibt und direkt die physische Adresse dieser Zeichenkette liefert.
Führen Sie für die Demo zunächst secret (als Root) aus, um die physische Adresse einer menschenlesbaren Zeichenkette zu erhalten:
make
sudo ./secret
Es sollte etwas Ähnliches wie dies ausgeben:
[+] Secret: If you can read this, this is really bad
[+] Physical address of secret: 0x390fff400
[+] Exit with Ctrl+C if you are done reading the secret
Während das secret-Programm läuft, starten Sie physical_reader. Der erste Parameter ist die physische Adresse, die von secret ausgegeben wurde. Wenn KASLR nicht deaktiviert ist, ist der zweite Parameter der Offset der direkten physischen Map.
taskset 0x1 ./physical_reader 0x390fff400 0xffff880000000000
Nach einigen Sekunden sollten Sie eine Ausgabe ähnlich dieser erhalten:
[+] Physical address : 0x390fff400
[+] Physical offset : 0xffff880000000000
[+] Reading virtual address: 0xffff880390fff400
If you can read this, this is really bad
memdump)Diese Demo gibt den Inhalt des Speichers aus. Wie Demo #3 und #4 verwendet sie die direkte physische Map, um den Inhalt des physischen Speichers in einem hexdump-ähnlichen Format auszugeben.
Da der physische Speicher wiederum viele nicht menschenlesbare Inhalte enthält, stellen wir ein Testwerkzeug bereit, um große Mengen des physischen Speichers mit menschenlesbaren Zeichenketten zu füllen.
Führen Sie für die Demo zunächst memory_filler aus, um den Speicher mit menschenlesbaren Zeichenketten zu füllen. Das erste Argument ist die Menge an Speicher (in Gigabyte), die gefüllt werden soll.
make
./memory_filler 9
Führen Sie dann das memdump-Werkzeug aus, um Speicherinhalte auszugeben. Wenn Sie zuvor memory_filler ausgeführt haben, sollten Sie einige Zeichenkettenfragmente sehen.
Wenn Sie Firefox oder Chrome mit mehreren geöffneten Tabs ausführen, sehen Sie möglicherweise auch Teile der Websites, die geöffnet sind oder kürzlich geschlossen wurden.
Der erste Parameter ist die physische Adresse, an der der Dump beginnen soll (leer lassen, um beim ersten Gigabyte zu beginnen). Der zweite Parameter ist die Anzahl der Bytes, die gelesen werden sollen; um alles zu lesen, geben Sie -1 an. Wenn KASLR nicht deaktiviert ist, ist der dritte Parameter der Offset der direkten physischen Map.
taskset 0x1 ./memdump 0x240000000 -1 0xffff880000000000 # start at 9 GB
Sie sollten einen Hexdump von Teilen des Speichers erhalten (möglicherweise sogar mit Geheimnissen wie Passwörtern, siehe Beispiel im Paper), z. B.: