Meltdown: Wie Prozessoren geschützten Speicher preisgaben

Am 3. Januar 2018 machten Forscher eine Sicherheitslücke öffentlich, die nicht in Software steckte, sondern in den Prozessoren selbst. Auf den meisten Intel-Prozessoren konnte jedes Programm den Speicher des Kernels lesen, also des Kerns des Betriebssystems. Auf vielen Systemen konnte es den gesamten Arbeitsspeicher des Computers lesen. Der Fix musste von den Betriebssystemen kommen. Windows, Linux und macOS änderten etwa zur gleichen Zeit, wie sie mit dem Speicher umgehen.

So funktionierte der Angriff

Moderne Prozessoren warten nicht jede Prüfung ab, bevor sie arbeiten. Um Zeit zu sparen, führen sie Befehle im Voraus und außer der Reihe aus und verwerfen die Ergebnisse, wenn eine Prüfung später fehlschlägt.

Auf Intel-Prozessoren lief der Versuch eines Programms, Kernel-Speicher zu lesen, einen Moment lang weiter. Erst dann stoppte ihn die Rechteprüfung. Der verbotene Wert wurde verworfen, doch das Programm hatte ihn bereits benutzt, um auf einen bestimmten Eintrag einer großen Tabelle zuzugreifen. Dieser Eintrag blieb im Cache, einem kleinen, schnellen Speicher im Prozessor. Danach maß das Programm mit einer Methode namens Flush+Reload, wie schnell jeder Eintrag der Tabelle lud. So erfuhr es den geheimen Wert. Wiederholte es diese Schritte, konnte es den gesamten Kernel-Speicher Byte für Byte lesen. Dafür brauchte es weder einen Fehler in der Software noch besondere Rechte.

Welche Prozessoren betroffen sind

Laut der Website der Forscher ist potenziell jeder Intel-Prozessor mit Out-of-Order-Ausführung seit 1995 betroffen, außer Itanium und Atom vor 2013. Ihr Fachartikel zeigt den Angriff auf Intel-Generationen seit 2010. Von ARMs eigenen Prozessordesigns ist nur der Cortex-A75 betroffen. Auch Samsungs Exynos M1 gab in Tests Daten preis. AMD erklärte laut dem Fachartikel, seine Prozessoren seien nicht betroffen.

Da die Schwachstelle in der Hardware liegt, spielt das Betriebssystem keine Rolle. Auf gemeinsam genutzten Servern konnten Programme in Containern, die sich ein Betriebssystem teilen, den Speicher des Hosts lesen. Das galt auch für manche Arten virtueller Maschinen.

Der Angriff ist schnell. Die Forscher lasen Kernel- und physischen Speicher mit 3,2 bis 503 Kilobyte pro Sekunde aus, je nach Rechner. Lagen die Daten schon im schnellsten Cache des Prozessors, dem L1-Cache, kamen sie noch schneller heraus. Die Fehlerquote betrug dann nur 0,003 %.

Warum das Auslesen des ganzen Speichers nur 5,6 erreicht

Die NVD, die US-amerikanische National Vulnerability Database, bewertet Meltdown mit 5,6 von 10 auf Version 3.0 der CVSS-Skala: mittel. Das liegt nicht daran, dass der Schaden klein wäre, sondern daran, wie der Angriff funktioniert. Der Angreifer muss bereits ein Programm mit normalen Benutzerrechten auf dem Computer ausführen. Die Skala nennt das einen lokalen Angriff. Der Angriff gilt als schwer durchführbar. Und er kann Daten nur lesen, nicht ändern oder löschen. Intels eigener Sicherheitshinweis vergibt denselben Wert. Shellshock, das über das Internet funktioniert, erreicht 9,8.

Der Fix und die Reaktion

Google Project Zero meldete die Lücke am 1. Juni 2017 an Intel, AMD und ARM. Die Technische Universität Graz und Cyberus Technology fanden sie unabhängig davon. 216 Tage lang blieb die Lücke geheim, während die Hersteller der Betriebssysteme Fixes vorbereiteten.

Der Fix heißt Kernel Page-Table Isolation (KPTI) und baut auf einem Forschungsentwurf namens KAISER auf. Seitentabellen sagen dem Prozessor, welchen Speicher ein Programm sehen kann. KPTI entfernt den Speicher des Kernels aus diesen Tabellen, solange normale Programme laufen. Microsoft veröffentlichte den Fix für Windows am 3. Januar 2018, etwa im Update KB4056892. Apple hatte bereits Fixes in iOS 11.2, macOS 10.13.2 und tvOS 11.2 ausgeliefert. Linux führte KPTI ein. Neuere Prozessoren beheben die Lücke in der Hardware.

Der Schutz kostet bei jedem Wechsel zwischen einem Programm und dem Kernel Zeit. Wie viel, hängt vom System ab und davon, welche Fixes eine Zahl umfasst:

Spectre heißen die beiden anderen Lücken im Bericht von Google Project Zero. Den größten Teil der Verlangsamung unter Windows verursachte laut Microsoft der Fix für die zweite Spectre-Variante. Der ungünstigste Fall bei Red Hat betrifft Anwendungen mit vielen Wechseln in den Kernel, etwa Datenbanken, die viele kleine Transaktionen verarbeiten. Er zeigt nicht, was der Meltdown-Fix allein kostet.