Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung

Der Aufhänger: Ein Fehler, den man nicht patchen konnte

Am 3. Januar 2018 änderte sich für die gesamte IT-Industrie etwas Grundlegendes. An diesem Tag veröffentlichten mehrere Forschungsgruppen – koordiniert und unter enormem Zeitdruck, weil die Nachricht bereits zu durchsickern begann – zwei eng verwandte Angriffe mit den Namen Meltdown und Spectre. Was sie beschrieben, war kein gewöhnlicher Softwarefehler. Es war keine vergessene Eingabeprüfung, kein Pufferüberlauf, kein schlampiger Code, den man in einem Nachmittag hätte reparieren können. Es war ein Konstruktionsprinzip. Genauer gesagt: dasselbe Prinzip, das praktisch jeden schnellen Prozessor der letzten zwei Jahrzehnte schnell gemacht hatte.

Die unbequeme Wahrheit lautete: Nahezu jeder moderne Mikroprozessor – die Intel-Chips in Laptops und Servern, die ARM-Kerne in Milliarden von Smartphones, die AMD-Prozessoren in Spielrechnern – teilte eine gemeinsame Schwäche. Sie steckte nicht in einem einzelnen fehlerhaften Bauteil, sondern in einer Optimierungstechnik namens spekulative Ausführung, die so tief in der Architektur verankert war, dass man sie nicht einfach abschalten konnte, ohne die Rechenleistung um Größenordnungen einbrechen zu lassen.

Für jemanden, der in der IT-Security arbeitet, ist das die interessanteste Sorte von Verwundbarkeit überhaupt. Denn Spectre und Meltdown zerstörten eine Annahme, auf der praktisch die gesamte Sicherheitsarchitektur der Informatik ruht: die Annahme, dass die logische Semantik eines Programms – was es berechnet – identisch ist mit seinem beobachtbaren Verhalten. Der Prozessor, so stellte sich heraus, tut im Verborgenen weit mehr, als die Programmiersprache je zu Gesicht bekommt. Und dieses Mehr hinterlässt Spuren.

Dieser Artikel nimmt dich mit auf die vollständige Strecke: von der Frage, warum Prozessoren überhaupt „raten", über den genauen Mechanismus, mit dem sich dieses Raten in ein Datenleck verwandeln lässt, bis zu der Unterscheidung zwischen Meltdown und Spectre, den Gegenmaßnahmen mitsamt ihrem Preis und der grundsätzlichen Lektion, die diese Angriffsklasse für das Nachdenken über Sicherheit bereithält.

Teil 1: Warum Prozessoren raten müssen

Die Kluft zwischen Rechenwerk und Speicher

Um zu verstehen, warum Spectre und Meltdown möglich sind, muss man ein Grundproblem der Computerarchitektur begreifen, das die Ingenieure seit Jahrzehnten umtreibt. Ein moderner Prozessorkern kann Rechenoperationen mit atemberaubender Geschwindigkeit ausführen – mehrere Milliarden pro Sekunde. Der Hauptspeicher hingegen ist im Vergleich dazu quälend langsam. Muss der Prozessor ein Datum aus dem RAM holen, vergehen dabei leicht mehrere hundert Taktzyklen. In dieser Zeit könnte er hunderte anderer Instruktionen abarbeiten.

Würde ein Kern einfach stur eine Instruktion nach der anderen ausführen und bei jedem Speicherzugriff warten, läge er die meiste Zeit brach. Die gesamte Geschichte der Prozessorleistung seit den 1990er Jahren ist im Kern die Geschichte des Kampfes gegen dieses Warten. Und die schärfste Waffe in diesem Kampf heißt: nicht warten, sondern weitermachen – und zwar auf Verdacht.

Out-of-Order- und spekulative Ausführung

Zwei eng verwandte Techniken bilden das Herzstück. Die erste ist die Out-of-Order-Ausführung: Der Prozessor führt Instruktionen nicht zwingend in der Reihenfolge aus, in der sie im Programm stehen, sondern in der Reihenfolge, in der ihre Eingaben verfügbar werden. Wartet eine Instruktion auf ein langsames Datum aus dem Speicher, arbeitet der Kern in der Zwischenzeit unabhängige spätere Instruktionen schon einmal ab. Erst ganz am Ende, beim sogenannten Retirement, werden die Ergebnisse wieder in die richtige Programmreihenfolge gebracht und offiziell wirksam.

Die zweite Technik ist die spekulative Ausführung im engeren Sinne. Programme sind voller Verzweigungen: „Wenn diese Bedingung wahr ist, tue A, sonst tue B." Ob die Bedingung wahr ist, hängt oft von einem Datum ab, das gerade noch aus dem langsamen Speicher unterwegs ist. Der Prozessor könnte warten – oder er könnte raten, wie die Verzweigung ausgehen wird, und schon einmal in die vermutete Richtung weiterrechnen. Genau das tut er. Eine Komponente namens Branch Predictor (Sprungvorhersage) merkt sich das bisherige Verhalten jeder Verzweigung und trifft auf dieser Grundlage eine Vorhersage. Moderne Sprungvorhersagen erreichen Trefferquoten von über 95 Prozent.

Rät der Prozessor richtig – was fast immer der Fall ist –, hat er wertvolle Zeit gewonnen: Die Ergebnisse liegen bereits vor, wenn die Bedingung sich endlich klärt. Rät er falsch, verwirft er die spekulativ berechneten Ergebnisse, setzt den Zustand zurück und rechnet in die korrekte Richtung weiter. Nach außen, auf der Ebene der Programmlogik, ist von der Fehlspekulation nichts zu sehen. Das Programm liefert exakt das Ergebnis, das es laut seiner Semantik liefern soll.

Der transiente Zwischenzustand

Und hier liegt der wunde Punkt, den ich für die eigentliche konzeptuelle Pointe der ganzen Geschichte halte. Die spekulativ ausgeführten Instruktionen – jene, die auf einer falschen Vorhersage beruhten und später verworfen wurden – nennt man transiente Instruktionen. Ihre architektonischen Effekte (der offiziell sichtbare Zustand: Registerinhalte, Speicherinhalte) werden sauber zurückgerollt. Aber ihre mikroarchitektonischen Effekte werden es nicht.

Denn während der spekulativen Ausführung hat der Prozessor womöglich Daten in den Cache geladen – jenen kleinen, schnellen Zwischenspeicher, der die Kluft zwischen Kern und RAM überbrückt. Wird eine Spekulation verworfen, macht der Prozessor die logischen Ergebnisse rückgängig, aber er räumt den Cache nicht wieder auf. Die geladenen Daten bleiben liegen. Und der Zustand des Caches ist messbar. Genau das ist die Bresche, durch die Spectre und Meltdown marschieren: Der Prozessor rollt zurück, was er berechnet hat, aber nicht die Spuren, die das Berechnen im Cache hinterlassen hat.

Teil 2: Der Cache als Verräter – der Seitenkanal

Was ist ein Seitenkanal?

Ein Seitenkanalangriff (side-channel attack) greift ein System nicht über die vorgesehene Schnittstelle an, sondern über eine unbeabsichtigte physikalische oder verhaltensbezogene Nebenwirkung seiner Arbeit. Der klassische Fall ist die Timing-Analyse: Eine kryptographische Operation, die für ein gesetztes Bit einen Sekundenbruchteil länger braucht als für ein gelöschtes, verrät über die messbare Zeit den geheimen Schlüssel, obwohl der Schlüssel selbst nie ausgegeben wurde. Der Angreifer hört gleichsam nicht auf das, was das System sagt, sondern darauf, wie es atmet.

Der Cache ist ein besonders ergiebiger Seitenkanal. Der entscheidende Punkt: Ein Speicherzugriff ist dramatisch schneller, wenn das gesuchte Datum bereits im Cache liegt (ein Cache-Hit, wenige Taktzyklen), als wenn es erst aus dem RAM geholt werden muss (ein Cache-Miss, hunderte Taktzyklen). Diese Zeitdifferenz ist so groß und so zuverlässig, dass ein Angreifer allein durch Zeitmessung feststellen kann, welche Speicheradressen kürzlich benutzt wurden – und durch wen.

Flush+Reload: die Messtechnik

Die in den Spectre- und Meltdown-Papieren verwendete Technik heißt Flush+Reload. Sie funktioniert in drei Schritten und setzt voraus, dass Angreifer und Opfer sich einen Speicherbereich teilen (etwa eine gemeinsam genutzte Bibliothek), was in der Praxis häufig der Fall ist.

Zuerst flusht (leert) der Angreifer eine bestimmte Cache-Zeile gezielt aus dem Cache – auf x86 genügt dafür die Instruktion clflush. Der zugehörige Speicher ist damit garantiert nicht mehr im schnellen Cache. Dann lässt der Angreifer das Opfer arbeiten. Zuletzt greift der Angreifer auf dieselbe Speicheradresse zu und misst die Zeit. War der Zugriff schnell, muss das Opfer diese Adresse zwischenzeitlich benutzt und damit in den Cache geladen haben. War er langsam, hat es das nicht getan. Aus einem einzigen Bit „schnell oder langsam" wird so Wissen über das Verhalten eines fremden Prozesses.

Die Kombination, die alles ermöglicht

Nun fügen sich die Teile zusammen. Die spekulative Ausführung erlaubt es dem Prozessor, kurzzeitig – transient – auf Daten zuzugreifen, auf die er eigentlich gar nicht zugreifen dürfte. Der Cache-Seitenkanal erlaubt es, diesen flüchtigen Zugriff im Nachhinein sichtbar zu machen. Der Trick, der beide verbindet, ist von bestechender Eleganz.

Der Angreifer bringt den Prozessor dazu, während der Spekulation ein geheimes Byte zu lesen. Dieses Byte darf er nicht direkt ausgeben – die Spekulation wird ja verworfen. Aber er kann das geheime Byte als Index benutzen, um auf ein großes, ihm selbst gehörendes Array zuzugreifen. Angenommen, das Geheimnis hat den Wert 65. Dann lädt die transiente Instruktion das Element an Position 65×4096 dieses Arrays in den Cache. Die Spekulation wird verworfen, das Byte 65 ist logisch nie „passiert" – aber die Cache-Zeile für Position 65×4096 ist warm.

Anschließend misst der Angreifer mit Flush+Reload alle 256 möglichen Positionen des Arrays durch. Genau eine ist schnell: die Nummer 65. Damit ist der geheime Wert extrahiert. Das Geheimnis wurde nie in ein Register geschrieben, nie ausgegeben, nie logisch berechnet – und ist dennoch entkommen, verschlüsselt in der Adresse eines Cache-Zugriffs. Der Faktor 4096 (eine Speicherseite) sorgt dabei dafür, dass benachbarte Werte nicht durch das automatische Vorausladen des Prozessors (Prefetching) verwischt werden.

Teil 3: Meltdown – das Einschmelzen der Grenze

Die heiligste Grenze des Betriebssystems

Meltdown (CVE-2017-5754), in der ursprünglichen Nummerierung als Variante 3 geführt, ist der spektakulärere und zugleich einfacher zu verstehende der beiden Angriffe. Um seine Wirkung zu ermessen, muss man die wichtigste Trennlinie eines jeden Betriebssystems kennen: die zwischen User Space und Kernel Space.

Anwendungsprogramme laufen im User Space mit eingeschränkten Rechten. Der Betriebssystemkern läuft im privilegierten Kernel Space und hat Zugriff auf alles – den gesamten physischen Speicher, die Daten aller Prozesse, kryptographische Schlüssel. Aus Effizienzgründen wird der Kernel-Speicher in den virtuellen Adressraum jedes Prozesses eingeblendet, aber durch ein Rechte-Bit geschützt: Versucht ein User-Space-Programm, auf eine als „privilegiert" markierte Adresse zuzugreifen, löst der Prozessor eine Schutzverletzung aus und bricht den Zugriff ab. Diese Grenze galt als absolut. Sie ist das Fundament, auf dem die Isolation zwischen Programmen – und zwischen Kunden auf demselben Cloud-Server – ruht.

Wie Meltdown die Grenze überwindet

Meltdown nutzt eine subtile Eigenschaft der Intel-Prozessoren jener Zeit aus: Die Prüfung des Rechte-Bits und der eigentliche Speicherzugriff geschahen nicht streng gleichzeitig. Der Prozessor lud den Wert der geschützten Kernel-Adresse spekulativ bereits, bevor die Rechteprüfung abgeschlossen war, und stellte ihn den nachfolgenden transienten Instruktionen kurzzeitig zur Verfügung. Erst danach schlug die Prüfung fehl und der Zugriff wurde mit einer Ausnahme (Exception) abgebrochen.

Dieses winzige Zeitfenster genügt. In den wenigen Taktzyklen, bevor die Ausnahme greift, führt der Angreifer genau die oben beschriebene Kodierung durch: Er liest das geschützte Byte und benutzt es als Index in sein eigenes Array. Die Ausnahme rollt die Programmlogik zurück, aber die Cache-Spur bleibt – und wird per Flush+Reload ausgelesen. Um die ständigen Ausnahmen sauber abzufangen, verwendet der Angreifer entweder eine Ausnahmebehandlung oder die elegantere Technik der Transaktionsspeicher (Intel TSX), die den Fehler unterdrückt.

Das erschütternde Ergebnis: Ein völlig unprivilegiertes Programm konnte auf diese Weise den gesamten Kernel-Speicher auslesen – und auf vielen Systemen damit den kompletten physischen Speicher der Maschine, mit Leseraten von mehreren Kilobyte pro Sekunde und nahezu fehlerfrei. In einer Cloud-Umgebung, in der viele Kunden sich physische Hardware teilen, ist das ein Albtraumszenario: Ein Mieter könnte prinzipiell die Geheimnisse eines anderen mitlesen. Betroffen waren praktisch alle Intel-Prozessoren seit etwa 2010; die meisten AMD-Prozessoren waren aufgrund einer strengeren Rechteprüfung von Meltdown nicht betroffen.

Teil 4: Spectre – den Prozessor gegen sich selbst wenden

Das raffiniertere, hartnäckigere Übel

Wenn Meltdown der Vorschlaghammer ist, dann ist Spectre das Florett. Spectre bricht nicht die Grenze zwischen User und Kernel innerhalb desselben Programms, sondern verleitet ein Opferprogramm dazu, seine eigenen Geheimnisse preiszugeben. Es bringt den Prozessor dazu, gegen die Interessen des Programms zu spekulieren, das er gerade ausführt. Spectre ist damit allgemeiner, schwerer auszunutzen – und weitaus schwerer zu beheben. Es existiert in mehreren Varianten.

Variante 1: Bounds Check Bypass

Spectre Variante 1 (CVE-2017-5753) trägt den Namen Bounds Check Bypass, Umgehung der Bereichsprüfung. Betrachten wir ein alltägliches Stück defensiven Codes:

if (x < array1_size)
    y = array2[array1[x] * 4096];

Diese Prüfung soll verhindern, dass mit einem zu großen x außerhalb des Arrays gelesen wird – ein Musterbeispiel für sauberes, sicheres Programmieren. Der Angreifer aber, der x kontrolliert, füttert das Programm zunächst viele Male mit gültigen Werten. Der Branch Predictor „lernt" dabei, dass die Bedingung stets wahr ist, und gewöhnt sich an, den if-Zweig zu nehmen. Dann übergibt der Angreifer ein bösartig großes x. Während der Prozessor noch darauf wartet, array1_size aus dem langsamen Speicher zu laden, spekuliert er anhand der gelernten Gewohnheit, dass die Bedingung wahr ist – und führt die geschützte Zeile transient aus, obwohl x weit außerhalb der Grenzen liegt.

Nun greift array1[x] auf beliebigen Speicher des Opferprozesses zu, und der gelesene geheime Wert wird – wieder über den Faktor 4096 – als Cache-Index in array2 kodiert. Die Spekulation wird verworfen, sobald array1_size eintrifft und die Bedingung als falsch entlarvt. Doch die Cache-Spur bleibt, und der Angreifer liest sie aus. Auf diese Weise lässt sich der gesamte Adressraum des Opfers Byte für Byte abgrasen. Besonders brisant: Auch der Kernel selbst enthält solche Muster, und über sie lässt sich Kernel-Speicher lesen.

Variante 2: Branch Target Injection

Spectre Variante 2 (CVE-2017-5715), Branch Target Injection, ist die perfideste Spielart. Sie zielt nicht auf bedingte Sprünge, sondern auf indirekte Sprünge – solche, bei denen die Zieladresse selbst erst berechnet werden muss (etwa bei virtuellen Funktionsaufrufen). Auch deren Ziel sagt der Prozessor voraus, gestützt auf einen Puffer namens Branch Target Buffer.

Der Angreifer vergiftet diesen Puffer gezielt: Er führt in seinem eigenen Prozess Sprünge so aus, dass der Prozessor lernt, ein bestimmtes indirektes Sprungziel im Opfer werde zu einer vom Angreifer gewählten Adresse führen. Führt das Opfer dann seinen indirekten Sprung aus, spekuliert der Prozessor an eine Adresse, die der Angreifer bestimmt hat – zu einem sogenannten Gadget, einem passenden Codeschnipsel im Opfer, das ein Geheimnis liest und in den Cache kodiert. Der Angreifer dirigiert den Kontrollfluss des Opfers gleichsam fernbedient, ganz ohne dessen Code zu verändern. Diese Variante ist besonders gefährlich, weil sie Prozessgrenzen und sogar die Isolation virtueller Maschinen überwinden kann.

Weitere Varianten

Auf die ersten drei folgten rasch weitere Mitglieder der Familie: Variante 4 (Speculative Store Bypass, CVE-2018-3639), die die spekulative Umgehung von Schreib-Lese-Abhängigkeiten ausnutzt; Foreshadow / L1TF (2018), das die Enklaven von Intel SGX und die L1-Datencache-Isolation angreift; sowie später die Klasse der MDS-Angriffe (Microarchitectural Data Sampling, u. a. RIDL, Fallout, ZombieLoad, 2019), die aus internen Prozessorpuffern lecken. Zusammengefasst werden sie unter dem Begriff transiente Ausführungsangriffe (transient execution attacks). Ich bin der Meinung, dass die wichtigste Einsicht dieser Reihe nicht in einer einzelnen Variante liegt, sondern in der Erkenntnis, dass es sich um eine ganze Angriffsklasse handelt – und dass jede Optimierung, die auf spekulativem Verhalten beruht, ein potenzieller Kandidat für den nächsten Angriff ist.

Teil 5: Die Gegenmaßnahmen und ihr Preis

Meltdown: die harte Trennung

Meltdown ließ sich vergleichsweise sauber, aber schmerzhaft eindämmen. Die Lösung heißt KPTI (Kernel Page-Table Isolation), hervorgegangen aus dem älteren Forschungsprojekt KAISER der TU Graz. Die Idee: Wenn das Problem darin besteht, dass Kernel-Speicher im Adressraum des User-Space eingeblendet ist, dann blendet man ihn eben aus. KPTI führt zwei getrennte Seitentabellen ein – eine für den User Space, in der der Kernel fast vollständig fehlt, und eine für den Kernel. Ist der Kernel-Speicher gar nicht erst adressierbar, kann ihn auch keine Spekulation lesen.

Der Preis dafür ist real: Jeder Wechsel zwischen User und Kernel – bei jedem Systemaufruf, jeder Unterbrechung – erfordert nun einen Wechsel der Seitentabelle und das Leeren von Übersetzungspuffern (TLB-Flush). Je nach Arbeitslast bedeutete das Leistungseinbußen im niedrigen bis mittleren zweistelligen Prozentbereich, besonders schmerzhaft bei systemaufruf-intensiven Serveranwendungen. Neuere Prozessoren beheben Meltdown direkt in Hardware, sodass KPTI dort abgeschaltet werden kann.

Spectre: der zähe Gegner

Spectre ist die eigentliche Dauerbaustelle, weil es kein simpler Implementierungsfehler ist, sondern eine Konsequenz des Grundprinzips. Gegen Variante 2 entwickelte Google die Technik Retpoline („return trampoline"): ein Compiler-Kniff, der indirekte Sprünge durch eine Konstruktion aus return-Befehlen ersetzt, die die verwundbare Sprungvorhersage ins Leere laufen lässt. Ergänzend führten die Prozessorhersteller per Microcode-Update neue Kontrollmechanismen ein (IBRS, STIBP, IBPB), mit denen sich die Sprungvorhersage über Sicherheitsgrenzen hinweg abschotten lässt – ebenfalls nicht umsonst zu haben.

Gegen Variante 1 gibt es keinen generischen Compiler-Schalter, weil die verwundbaren Muster überall im Code lauern. Die verbreitetste Abwehr ist die Einfügung einer Spekulationsbarriere (lfence auf x86) nach sicherheitskritischen Bereichsprüfungen, die den Prozessor zwingt, an dieser Stelle nicht weiterzuspekulieren. Weil man solche Barrieren aber nicht überall setzen kann, ohne die Leistung zu ruinieren, müssen die kritischen Stellen mühsam identifiziert werden. Auf der Ebene der Webbrowser wurden zusätzlich Gegenmaßnahmen wie Site Isolation (jede Website in einem eigenen Prozess) und die Verringerung der Timer-Auflösung eingeführt, um Angreifern die für Flush+Reload nötige präzise Zeitmessung zu erschweren – nachdem gezeigt worden war, dass sich Spectre sogar aus JavaScript im Browser heraus ausnutzen ließ.

Die unbequeme Bilanz

Die entscheidende, unangenehme Erkenntnis lautet: Spectre lässt sich nicht vollständig „patchen". Solange Prozessoren spekulieren – und ohne Spekulation wären sie inakzeptabel langsam –, bleibt die grundsätzliche Angriffsfläche bestehen. Die Verteidigung besteht aus einem Flickwerk gezielter Maßnahmen an bekannten Stellen, kombiniert mit architektonischen Verbesserungen in neuen Prozessorgenerationen. Es ist, ich bin der Meinung, eines der klarsten Beispiele dafür, dass Sicherheit und Leistung nicht immer harmonieren, sondern manchmal in einem echten, physikalisch verankerten Zielkonflikt stehen.

Teil 6: Die tiefere Lektion für die Sicherheit

Warum sollte das jemanden interessieren, der nicht selbst Prozessoren entwirft? Weil Spectre und Meltdown eine Grenze verschoben haben, die für das gesamte Sicherheitsdenken gilt. Bis 2018 arbeitete die IT-Security überwiegend auf der Ebene der Abstraktion: Man sicherte Schnittstellen ab, prüfte Eingaben, verwaltete Rechte, verschlüsselte Daten – alles auf der Ebene dessen, was ein Programm logisch tut. Die darunterliegende Hardware galt als vertrauenswürdiges Fundament, als korrekte Umsetzung der Programmiersprachen-Semantik.

Diese Annahme ist gefallen. Spectre und Meltdown zeigen, dass die Abstraktion leckt – dass die Implementierung unterhalb der logischen Ebene beobachtbare Nebenwirkungen hat, die sich in Angriffe verwandeln lassen. Ein Programm kann formal korrekt und frei von jedem klassischen Fehler sein und dennoch Geheimnisse preisgeben, weil die Maschine, die es ausführt, mehr tut, als der Quelltext sagt. Das ist eine grundlegend andere Art, über Sicherheit nachzudenken: Nicht mehr nur „Was berechnet dieses Programm?", sondern „Welche Spuren hinterlässt das Berechnen im physikalischen Substrat?"

Diese Verschiebung ist bis heute wirksam. Sie hat das Feld der mikroarchitektonischen Sicherheit als eigene Disziplin etabliert, sie hat Hardwarehersteller gezwungen, Sicherheit von Anfang an in den Chip-Entwurf einzubeziehen (statt sie der Software zu überlassen), und sie hat die Frage aufgeworfen, wie viele weitere „lecke Abstraktionen" noch unentdeckt in unseren Systemen schlummern. Die MDS-Angriffe von 2019 und spätere Funde legen nahe: Es waren nicht die letzten.

Erkenntnis zum Mitnehmen

Wenn du eine einzige Sache aus diesem Artikel mitnimmst, dann diese: Sicherheit lebt nicht nur in der Logik eines Systems, sondern auch in seinem physikalischen Verhalten – und beides kann auseinanderfallen. Spectre und Meltdown waren keine Programmierfehler, die jemand hätte vermeiden können, sondern die unvermeidliche Kehrseite einer Optimierung, die alle wollten und von der alle profitierten. Die Geschwindigkeit unserer Prozessoren ist zu einem guten Teil erkauft durch spekulatives Raten – und dieses Raten hinterlässt Spuren, die sich auslesen lassen.

Der praktische Handlungsanstoß daraus ist weder Panik noch Ignoranz, sondern ein geschärftes Modell von Vertrauensgrenzen. Wer sicherheitskritische Systeme baut oder betreibt, sollte wissen: Das Teilen physischer Hardware zwischen gegenseitig misstrauischen Parteien – der Normalfall in jeder Public Cloud – ist keine perfekte Isolation, sondern eine Abwägung. Die richtige Frage lautet nicht „Ist mein Code korrekt?", sondern „Welche Annahmen über die darunterliegende Schicht mache ich stillschweigend – und was passiert, wenn eine davon leckt?" Halte Systeme aktuell (die Microcode- und Kernel-Updates gegen diese Angriffe sind real und wirksam), und behandle die Grenze zwischen deinem Code und der Maschine, die ihn ausführt, als das, was sie ist: eine nützliche Fiktion, die meistens hält – aber eben nicht immer.

Querverweise im Vault

Spectre und Meltdown verbinden sich mit mehreren Themen, die bereits in diesem Vault liegen. Der Angriff verwandelt eine reine Zeitdifferenz in einen Informationskanal – dieselbe Idee, wie sie Uhren, die ihre eigene Unsicherheit kennen: Google Spanner, TrueTime und die Beherrschung der Zeit in der Cloud von der konstruktiven Seite beleuchtet, wo genaue Zeit zum Werkzeug wird, statt zum Leck. Als Kapitel der IT-Security schließt der Artikel unmittelbar an Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer an: Beide zeigen, wie eine physikalische bzw. mathematische Entwicklung eine als sicher geglaubte Grundlage untergräbt. Und die Cloud-Dimension – das Teilen physischer Hardware zwischen misstrauischen Parteien – berührt die Fragen der Systemkoordination aus Wie Maschinen sich einig werden: Verteilter Konsens von FLP über Paxos zu Raft.

Reflexionsfrage zum Schluss

Spectre und Meltdown wurden möglich, weil eine Optimierung, die fast immer nützt, in seltenen, gezielt herbeigeführten Fällen zum Leck wird. Wo in deinen eigenen Systemen – im Code, in der Architektur, in den Betriebsabläufen – hast du eine Optimierung eingeführt, die „fast immer" das Richtige tut? Und weißt du, was genau in jenen seltenen Fällen passiert, in denen sie es nicht tut?

Quellen

• Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D., Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher, T., Schwarz, M., Yarom, Y.: Spectre Attacks: Exploiting Speculative Execution. IEEE Symposium on Security and Privacy (S&P) 2019; arXiv:1801.01203. https://arxiv.org/abs/1801.01203
• Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W., Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D., Yarom, Y., Hamburg, M.: Meltdown: Reading Kernel Memory from User Space. USENIX Security Symposium 2018; arXiv:1801.01207. https://arxiv.org/abs/1801.01207
• Offizielle Informationsseite zu Meltdown und Spectre: https://meltdownattack.com/
• Horn, J. (Google Project Zero): Reading privileged memory with a side-channel. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
• Canella, C., Van Bulck, J., Schwarz, M. et al.: A Systematic Evaluation of Transient Execution Attacks and Defenses. USENIX Security 2019; arXiv:1811.05441. https://arxiv.org/abs/1811.05441
• Wikipedia: Spectre (security vulnerability). https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

Hinweis zur wissenschaftlichen Absicherung: Die technischen Aussagen dieses Artikels stützen sich auf die zwei begutachteten Originalarbeiten (IEEE S&P 2019 bzw. USENIX Security 2018) sowie die systematische Taxonomie von Canella et al. Wo ich über die gesicherte Faktenlage hinaus eine Einordnung vornehme, ist dies mit „Ich bin der Meinung, dass ..." gekennzeichnet.

← All articles