Sicherheitslücken Spectre & Meltdown: Ein Erklärungsversuch

Special 11.01.2018 um 11:15 Uhr Torsten Vogel Als bevorzugte Quelle auf Google hinzufügen

Die Gefahr durch und die Lösung von Sicherheitsproblemen in allen aktuellen CPUs beherrscht seit letzter Woche die Medienlandschaft - weit über den IT-Bereich hinaus. Aber was sind Spectre und Meltdown eigentlich? Wie funktionieren sie?

Eigentlich sollte die Bombe erst diese Woche platzen - oder genauer gesagt erst entschärft und dann öffentlich gemacht werden, um das Schadenspotenzial zu minimieren. Weil aber auch Verschwiegenheitsvereinbarungen Lücken haben, findet sich seit Tagen ein buntes Sammelsurium von Informationen über Spectre und Meltdown im Netz. Während die Gerüchteküche sich zunehmend auf die Performance der Lösungsversuche konzentriert, möchten wir uns an einer verständlichen Erklärung der Mechanismen dahinter versuchen. Denn nur was man versteht, kann man auch richtig einschätzen.

Eine Einschränkung vornweg: Als Fachmagazin für Consumer-Technik kennt sich PC Games Hardware gut mit der Architektur von x86-Prozessoren aus, eine vollständige Analyse des Schadenspotenzials auf Seite der Betriebssysteme sprengt aber unseren Rahmen und viele Details der Angriffswege und Gegenmaßnahmen werden bewusst geheim gehalten. Dieser Artikel soll als Grundlage für weitere Updates und für eine sachliche, technische Diskussion dienen - das letzte Wort zu Spectre und Meltdown wird aber vermutlich erst in einigen Jahren geschrieben.

Auf dieser Seite

1 Spectre & Meltdown: Ein Exkurs zum CPU-Design

Spectre & Meltdown: Ein Exkurs zum CPU-Design

Bei Spectre und Meltdown handelt es nicht um "Bugs" oder "Sicherheitslücken", sondern um Hacks im ganz klassischen Sinne. Nominell arbeiten Hard- und Software fehlerfrei wie vom Entwickler vorgesehen, bieten aber über die spezifizierte Funktionsweise hinaus Möglichkeiten, von deren Existenz selbst den Entwicklern unbekannt war. Und je eine erlaubt Angreifern das Aufrufen und anschließende Auslesen von Daten, die sie laut nominellem Programmablauf weder aufrufen noch auslesen. Klingt kompliziert? Ist es auch.

Grundlage 1: Out of Order

Moderne CPUs brauchen mehrere Taktzyklen für Berechnungen, sodass es zwischen aufeinander aufbauenden Instruktionen zu Wartezeiten kommen kann. Um Leerlauf zu vermeiden, arbeiten seit Intels erstem Pentium daher beinahe alle x86-CPUs (und nicht nur diese) Out of Order (OoO). Das heißt die Prozessoren selbst und nicht mehr die Software entscheiden über die Reihenfolge der Befehlsabarbeitung und können zur Vermeidung einzelne Aufgaben vorziehen, um die Recheneinheiten dauerhaft auszulasten.

Grundlage 2: Speculative Execution

Quelle: AMD Nur die kleinen, als ALU und FPU beschrifteten Bereiche dieses Ryzen-Kerns (selbst nur ein kleiner Teil des Silizium-Chips) führen tatsächlich Berechnungen durch. Die ungleich größere Neural-Net-Prediction-Einheit und der Scheduler dienen allein der OoO-Verwaltung und spekulativen Befehlsausführung. Beinahe synonym verwendet wird Speculative Execution, denn diese Erweiterung nutzen quasi alle OoO-CPUs. Ausgestattet mit einer (Sprung-)Vorhersage-Einheit können sie nicht nur bereits in Auftrag gegebene Befehle abarbeiten, sondern auch spekulativ kommende Einträge im Programmcode ausführen. Auch hier entscheidet die CPU selbst anhand relativ primitiver Analysen, welche Instruktionen vermutlich als nächstes aufgerufen werden - würde Speculative Execution auf komplexe Informationen und viel zu langsame Systemprozesse warten, brächte sie keinen Geschwindigkeitsvorteil. Innerhalb des nominellen Programmflusses ist dies auch kein Problem. Wird eine Instruktion später doch nicht aufgerufen, verwirft der Prozessor das Ergebnis und die Software erfährt nichts vom gesamten Vorgang. War die Vorhersage dagegen korrekt, "berechnet" die CPU das geforderte Ergebnis aus Sicht des Prozesses einfach nur ungewöhnlich schnell.

Grundlage 3: Caching

Ladevorgänge sind ein häufiger Grund für lange Befehls-Wartezeiten, weswegen moderne Computer diese mit diversen Zwischenspeichern vermeiden wollen - auf den RAM folgen L3-, L2- und L1-Cache. Schnellere Ebenen sind hierbei teurer und deswegen auch kleiner, spätestens beim L1-Cache unmittelbar neben den Recheneinheiten ist vor allem der Verwaltungsaufwand für mehr als ein paar Kilobyte kaum realisierbar. Aber auch die L3-Caches sind mit wenigen Megabyte so viel kleiner als der mehrere Gigabyte große Hauptspeicher, dass nur noch Programmfragmente vorgehalten werden können. Welche das sind, entscheidet erneut der Prozessor selbst - eine (Sicherheits-)Analyse durch das Betriebssystem würde den ganzen Cache wirkungslos machen, da dieses selbst auf Daten im Hauptspeicher angewiesen ist.

Grundlage 4: Privilege Levels

Kein CPU-, sondern ein Betriebssystem-Feature ist die Speicherunterteilung. Konkret arbeitet jeder Prozess in einem eigenen virtuellen Adressraum ohne direkten Kontakt zu anderen Programmen mit Ausnahme des Betriebssystems. Dieses trennt einen Teil des virtuellen Adressraumes jedes Prozesses für eigene Zwecke ab, den sogenannten Kernel-Space. Das Programm wiederum kann nur in seinem eigenen, User-Space genannten Teil arbeiten - möchte es Daten von außerhalb nutzen, muss es diese via Syscall vom Betriebssystem anfordern und auf die Lieferung warten. Dieser Sicherheitsmechanismus ist auf CPU-Ebene durch sogenannte Privilege Level implementiert: Für bestimmte Befehle, insbesondere Zugriffe auf geschützte Betriebssystem-Daten im Kernel-Space, muss die CPU erst durch das Betriebssystem in den höchst privilegierten Modus versetzt werden. Ein User-Space-Prozess kann also nominell nie Zugriff auf Daten außerhalb desselben erhalten, solange ihn das Betriebssystem dabei nicht unterstützt. Versucht er es dennoch, wird die Überschreitung des Privilege-Levels registriert und das Betriebssystem kann den Prozess beenden, bevor er die angeforderten Daten erhält.