Die Hardware-Einfallstore "Spectre" und "Meltdown" haben Anfang 2018 für fette Schlagzeilen gesorgt: Sie nutzen einen Nebeneffekt moderner Computerchips und erlauben Einblicke in Informationen, die eigentlich streng geheim gehalten werden müssen. Um diese abzugreifen, ist zwar ein raffinierter Angriff erforderlich – er ist aber eben nicht unmöglich. Und es sieht ganz so aus, als sei den Konstrukteuren der Computerchips diese Möglichkeit, fremde Daten auszuspähen, schlicht nicht in den Sinn gekommen.

Welche Schwachstelle haben die Chips?

Moderne Rechner erreichen ihre hohen Leistungen insbesondere dadurch, dass sie alles tun, um ihre internen Bauteile möglichst nicht unbeschäftigt zu lassen. Leerlaufzeiten überbrückt der Prozessor, indem er mehrere Programme konkurrierend ausführt ("multithreading"). Sowie eines von ihnen in den Wartestand gerät, schaltet er auf ein anderes, unmittelbar aktionsfähiges Programm um. Das bedingt, dass alle diese Programme sich nicht nur den Prozessor, sondern auch den Arbeitsspeicher teilen. Vor allem in Computern, deren Leistung jedermann über das Internet mieten kann (die "Cloud"), weiß der Auftraggeber nie, mit wem zusammen sein Programm in einen Prozessor gerät. Ein räuberisches Programm könnte also theoretisch von seinem Nachbarn sensible Daten abgreifen; denn es gibt in der Hardware des Arbeitsspeichers keine Schranken, die es daran hindern würden.

Also muss der Schutz der – eigenen wie fremden – Daten auf andere Weise gewährleistet werden. Deshalb verbindet der Prozessor jeden Maschinenbefehl, der einen Speicherplatz betrifft, mit einer Zulässigkeitsabfrage: Liegt die Nummer (die "Adresse") des angeforderten Speicherplatzes innerhalb des dem Programm zugewiesenen Bereichs? Diese Abfrage ist nicht explizit Bestandteil des Programms, das der Chip zur Ausführung entgegennimmt, insbesondere kann ein Programmierer sie nicht einfach weglassen. Vielmehr löst der Prozessor jeden Maschinenbefehl (zum Beispiel "hole die Zahlen, die in den Speicherplätzen X und Y stehen, und multipliziere sie miteinander") in eine Folge von Mikroinstruktionen auf; eine von ihnen ist die genannte Abfrage.

Multithreading allein reicht allerdings noch nicht aus, um die Rechenwerke ausreichend auszulasten. Wollte der Prozessor – das "dirigierende" Bauteil auf den Chip – ein Programm so abarbeiten, wie es geschrieben ist, dann müsste zum Beispiel das Teil, das zwei Zahlen miteinander multipliziert, darauf warten, bis diese Zahlen aus dem Arbeitsspeicher eingetroffen sind. Das kann bis zu 100-mal so lange dauern wie das Rechnen selbst. Es ist daher zweckmäßig, Speicherinhalte anzufordern, die erst ein paar Befehle später benötigt werden. Dann stehen die Daten schon bereit, wenn sie an der Reihe sind. Eigens für deren Zwischenlagerung gibt es den so genannten Cache, einen kleinen, aber sehr schnell verfügbaren Speicher im Prozessor selbst. Der Rechner geht gewissermaßen nicht in die weitläufige Bibliothek, um in einem Buch nachzusehen; vielmehr lässt er einen Sklaven schon vorab eine Kopie der Buchseite anfertigen und auf seinem Schreibtisch ablegen. Dieser ist gerade so groß, dass der Prozessor jeden Zettel darauf rasch und mühelos lesen kann. Die Ergebnisse seiner Arbeit schreibt er ebenfalls nicht unmittelbar in den Arbeitsspeicher, sondern auf einen Zettel. Das spart Zeit, wenn er, wie häufig, das Ergebnis unmittelbar weiterverwenden will. Das endgültige Wegräumen in den Arbeitsspeicher erledigt wieder ein Sklave, ohne den Betrieb aufzuhalten.

Die Mikroinstruktionen, in die jeder Befehl aufgelöst wird, werden also nicht unbedingt der Reihe nach abgearbeitet, sondern jede dann, wenn ein geeigneter Sklave verfügbar ist ("out-of-order execution"). Dieser Vorgriff auf zukünftige Aufgaben geht sogar über Verzweigungspunkte im Programm hinaus: An manchen Stellen im Programm entscheidet sich abhängig von einem unmittelbar zuvor berechneten Wert, ob die Ausführung an dem nachfolgenden Maschinenbefehl oder an einer anderen Stelle fortzusetzen ist. Statt diese Entscheidung abzuwarten und damit den Betrieb aufzuhalten, wählt der Prozessor von den beiden möglichen Wegen einen aus – zum Beispiel den, der in der Vergangenheit häufiger vorkam – und lässt die zugehörigen Mikroinstruktionen "auf Verdacht" ablaufen ("spekulative Ausführung"). Wenn die Entscheidung anders ausgeht als vermutet, versetzt sich der Prozessor in den vorigen Stand der Dinge zurück und arbeitet von dort aus weiter. Die bis dahin fälschlich ausgeführten Instruktionen bleiben einfach unwirksam, denn sie haben allenfalls ein paar neue Zettel auf dem Schreibtisch abgelegt, aber keine Spuren im Arbeitsspeicher hinterlassen. Natürlich wird der Wegräumsklave erst auf den Weg geschickt, wenn der zugehörige Zettel keinen Vorläufigkeitsvermerk mehr trägt.

Wie stößt Schadsoftware in die Sicherheitslücke?

Der Angriff auf geschützte Speicherinhalte verläuft nun so: Der Bösewicht schreibt einen Maschinenbefehl, der einen unzulässigen Zugriff auf fremden Speicherplatz enthält. Außerdem arrangiert er es so, dass die genannte Zulässigkeitsabfrage aufgehalten wird, so dass deren Wirkung später eintritt als der Zugriff selbst. Und diese Befehle platziert er drittens hinter den Ast einer Verzweigung, der sich hinterher als der falsche herausstellt. Also wird der verbotene Zugriff nur spekulativ ausgeführt. Irgendwann kommt der Prozessor dahinter, dass der Befehl nicht hätte ausgeführt werden sollen, weil das Programm mit dem anderen Zweig weiterging. Daraufhin versetzt er sich zurück und macht damit alle Zettel, die infolge des verbotenen Zugriffs beschrieben wurden, unzugänglich. Insbesondere verfolgt er die Frage, ob der Zugriff überhaupt erlaubt war, nicht weiter, und die übliche Folge – Abbruch des Programms wegen unzulässigen Zugriffs – bleibt aus.

Nun ist zwar die gestohlene Information im Cache. Nehmen wir beispielsweise an, es handele sich um den Buchstaben B aus einem Dokument eines anderen Nutzers. Der Bösewicht hat allerdings keine Möglichkeit, diese Information irgendwo hinzuspeichern, wo er sie nutzen kann. Damit ist der Datenschutz gewährleistet – dachten die Chipdesigner. Aber bevor die Sache mit der falschen Verzweigung auffliegt, interpretiert das bösartige Programm die gestohlene Information, im Beispiel das B, als eine natürliche Zahl, in diesem Fall 66, und lädt ein völlig harmloses Datenstück aus seinem eigenen Speicherbereich in den Cache, und zwar das mit der Adresse 66. (Dieses Interpretieren ist nicht schwer, denn der Buchstabe B im üblichen ASCII-Kode und die Zahl 66 haben dieselbe Binärdarstellung.)

Auch dieser Zettel wird durch das Zurücksetzen unzugänglich gemacht; aber er bleibt auf dem Schreibtisch liegen. Nun lädt das Bösewichtprogramm seinen eigenen Speicherbereich Stück für Stück in den Cache und misst jedes Mal die Zeit, die der Ladevorgang in Anspruch nimmt. Zeitmessen ist einfach: Auf dem Prozessor sitzt auch ein Taktzähler, also ein Element, das in jedem elementaren Maschinentakt seinen Inhalt um eins hochzählt. Den liest das Programm vorher und nachher ab und berechnet die Differenz.

Der Prozessor müsste jetzt für jede dieser Anforderungen einen Sklaven zum Speicher schicken. Aber vorher schaut er routinemäßig nach, ob der angeforderte Inhalt – warum auch immer – bereits auf einem der Zettel auf dem Schreibtisch steht. In diesem Fall erübrigt sich der Speicherzugriff, und das Datenstück steht früher zur Verfügung – messbar früher. Durch Vergleich der Zugriffszeiten erkennt das Bösewichtprogramm die Adresse des einen Datenstücks, das bereits – unzulässigerweise hochgeladen – im Cache war, und damit die gestohlene Information: Weil das Datenstück Nummer 66 schneller verfügbar ist als alle anderen, weiß das Programm jetzt, dass die gestohlene Information ein B war.

Das ist das Grundprinzip des Angriffs. Die Einzelheiten sind entsprechend der komplizierten Arbeitsweise des Prozessors noch deutlich verwickelter. So muss das Bösewichtprogramm vor dem eigentlichen Angriff den Cache leeren (das Fachausdruck lautet "flush" wie Toilettenspülung), um falsch positive Meldungen kurzer Zugriffszeit zu vermeiden. Darüber hinaus muss es weitere Vorkehrungen treffen, um den Prozessor – dessen Arbeitsweise es ja nur indirekt beeinflussen kann – zu den gewünschten Aktionen zu veranlassen. Bislang sind zwei deutlich verschiedene Angriffsszenarien ausgearbeitet worden, die von ihren Entdeckern "Meltdown" und "Spectre" getauft wurden.

Selbst ein erfolgreicher Angriff läuft auf ein Stochern im Nebel hinaus; denn wo im Arbeitsspeicher der Prozessor welchem Programm seinen Platz zuweist, hängt davon ab, in welcher Reihenfolge diese Programme eintreffen. Der Bösewicht kann diese Information weder abfragen noch erschließen. Also bleibt ihm nichts übrig, als wahllos den ganzen Speicher abzuklappern und hinterher die Beute in Augenschein zu nehmen.

Das klingt nach mühsamer Arbeit mit ungewissem Erfolg. Allerdings sind moderne Prozessoren ungeheuer schnell. Ein einzelner Zugriff bringt zwar nur ein einziges Byte, was ungefähr einem Textbuchstaben entspricht. Aber eine geschickt programmierte Attacke holt unter günstigen Umständen 500 Kilobyte pro Sekunde aus dem Speicher heraus. Über solche Datenraten könnte ein Videokonsument zwar nur müde lächeln; aber zum Ausspähen und Missbrauchen zahlreicher Passwörter reicht das allemal.

Wie schützt man die Achillesferse der Rechner?

Wenn der Prozessor aus dem Ruhezustand hochfährt, lädt er ein einziges Programm stets als erstes, nämlich sein eigenes internes Betriebssystem. Wenn die Plätze im Arbeitsspeicher schön der Reihe nach besetzt würden, stünde also das Betriebssystem stets ganz vorne und wäre obendrein ein besonders lohnendes Angriffsziel. Aber dagegen haben die Betreiber auf der Softwareebene bereits Vorkehrungen getroffen: Bei jedem Hochfahren lädt der Computer das Betriebssystem an eine andere, zufällig bestimmte Stelle. Auch diese Maßnahme, die seit 2013 standardmäßig angewandt wird, kann man mit einem gezielten Angriff unterlaufen. Dagegen wiederum gibt es eine Softwareabhilfe namens KAISER; und es trifft sich günstig, dass KAISER auch gegen „Meltdown“ hilft – meistens.

Verschiedene Gruppen rund um den Globus haben die beschriebenen Schwachstellen entdeckt, teils unabhängig voneinander, teils in Zusammenarbeit. Zu den Beteiligten zählen insbesondere Jann Horn vom "Project Zero", das von Google betrieben wird, ein selbstständiger Kryptografie-Experte namens Paul Kocher und eine große Gruppe an der Technischen Universität Graz. Wie es sich gehört, haben die Forscher ihren Fund bereits im vergangenen Sommer den Hardwareherstellern mitgeteilt und erst jetzt veröffentlicht. Ob andere Leute die Idee schon vorher hatten und vielleicht schon genutzt haben, ist nicht bekannt. Eine Attacke dieser Art hinterlässt keine verwertbaren Spuren im Rechner.

Wie hoch ist die Gefahr einzuschätzen? Darüber gehen die Meinungen zurzeit noch weit auseinander. Erste panikartige Alarmrufe, man müsse alle existierenden Chips wegwerfen und durch neue, besser abgesicherte ersetzen – die es noch nicht gibt –, sind inzwischen verstummt. Eine immerhin realisierbare Option besteht darin, die Out-of-Order-Execution generell abzuschalten und dabei einen Leistungsverlust von bis zu einem Drittel in Kauf zu nehmen. Ganz so drastisch muss man anscheinend nicht vorgehen: Möglicherweise genügt es, den vorauseilenden Gehorsam des Prozessors in seiner Reichweite auf wenige Instruktionen zu beschränken und damit die dem Angreifer verfügbare Zeit zu verkürzen.

Allem Anschein nach ist das Loch auf der Softwareebene nicht vollständig zu stopfen. Immerhin kann ein Bösewicht die Daten des attackierten Computers nur auslesen, aber nicht verändern. Und sein Programm muss auf dem Computer des Opfers laufen. Diese Eigenschaft hat es mit den allgegenwärtigen Schadprogrammen ("Trojanern") gemein. Entsprechend gelten die üblichen Empfehlungen: Passwörter häufig wechseln und keine suspekten Programme aus dem Internet laden.

Unterdessen helfen Software-Updates, die von den Betriebssystemherstellern nach und nach bereitgestellt werden. Sie verringern indes nur das Risiko, dass Angriffe die Sicherheitslücken ausnutzen – und erkaufen sich den Sicherheitsgewinn zudem mit mehr oder weniger spürbaren Leistungseinbußen. Endgültige Abhilfe wird wohl erst mit der nächsten Hardwaregeneration kommen – und deren Designer vor knifflige Aufgaben stellen. Denn die Chips leiden nicht etwa unter einem Konstruktionsfehler, sondern darunter, dass sie so funktionieren, wie sie sollen, und dabei eben nur durch physikalische Nebeneffekte Informationen preisgeben.