Editorial: Kernschmelze im Prozessor

Eigentlich sollte die Bombe erst am 09.01. platzen, doch dann schossen die Spekulationen schon ein paar Tage vorher ins Kraut: Mit Meltdown und Spectre wurden bereits Mitte letzten Jahres zwei Sicherheitslücken entdeckt, die die eh schon erbärmlichen Überreste dessen, was wir noch an Computersicherheit haben, mehr oder weniger endgültig begraben. Und das Schlimme: Da der Fehler in der Hardware steckt, reicht es nicht, einzelne Software-Teile zu flicken. Vielmehr müssen gleich mehrere zentrale Software-Komponenten umgestellt werden, um alle Einfallstore für Meltdown und Spectre zu schließen. Dabei dürfte es durchaus mehrere Schleifen geben, während derer immer neue Angriffsvektoren gefunden werden, und entsprechend auch neue Software-Patches nötig sind. Da der Fehler in der Hardware sitzt, wird man in vielen Fällen auch nicht umhin kommen, die Hardware auszutauschen. Es gibt gar bereits Spekulationen, dass Intel, der (nach Umsatz, nicht jedoch nach Stückzahl) weltweit führende Prozessorhersteller zu einem weltweiten milliardenschweren Rückruf insbesondere seiner Server-Prozessoren gezwungen sein könnte.

Kernschmelze im Prozessor
Bild: ThorstenSchmitt- fotolia.com / Bearbeitung: teltarif.de Server-Anbieter, allen voran Anbieter von standardisierten virtuellen Mietservern in der Cloud, werden als erste reagieren und ihre Systeme updaten müssen, um zumindest dem Meltdown-Angriff zu entgehen. Andernfalls droht Datendiebstahl in großem Umfang: Passwörter, E-Mail-Adressen, Zugangsdaten, Kundenlisten, halt all das, was auf Servern so gespeichert wird. Immerhin stehen mittlerweile Patches bereit, die verhindern sollen, dass Cloud-Kunden sich gegenseitig die Daten klauen. Allerdings verlangsamen diese die Ausführung von Programmen teils drastisch. Und die Meltdown-Patches helfen nicht gegen Spectre.

Zwar ist Spectre deutlich komplexer und folglich auch schwieriger auszunutzen als Meltdown, aber aus demselben Grund ist es auch deutlich schwieriger, Software-Patches gegen Spectre zu entwickeln. Mit der nun erfolgten Veröffentlichung der Details von Spectre geht das Rennen zwischen Code-Knackern und Sicherheitsforschern in die heiße Phase. Sollten die Code-Knacker gewinnen, und sollte es Intel nicht gelingen, per Microcode-Update das Einfallstor für Spectre zu schließen, könnten Millionen von Website-Betreibern gezwungen sein, aus der Cloud zurück auf klassische Mietserver zu migrieren, weil deren Nutzerdaten in der Cloud nicht mehr sicher sind.

Auch Privat-Anwender betroffen

Die allereinfachste Version von Meltdown ermöglicht es, auf beliebige Daten innerhalb eines laufenden Programms zuzugreifen. Das klingt jetzt erstmal nicht nach einem Problem, denn grundsätzlich kann jedes Programm vollumfänglich auf seine eigenen Daten zugreifen, dafür braucht es nicht Meltdown. Doch Meltdown innerhalb eines Programms wird dann zum Problem, wenn Teile eines Programms vor anderen Teilen geschützt sind. Beispielsweise darf der Javascript-Code einer Webseite weder auf die diversen Passwörter und Cookies zugreifen, die in dem Browser gespeichert sind, noch auf die Daten von anderen Webseiten, die in anderen Tabs geöffnet sind. Gelingt es nun den Code-Knackern, Meltdown in Javascript auszuführen, und ich fürchte, das wird ihnen gelingen, dann sind alle diese Daten nicht mehr sicher!

Vom Prinzip her lässt sich Meltdown in jedem Code verstecken, der irgendwo in einer Sandbox ausgeführt wird: Javascript im Webbrowser, PDF im Dokumentenreader, Postscript im Drucker, Formeln in Excel usw. usf. Skripte stecken heutzutage überall, und mit Meltdown steckt in so gut wie jedem Skript eine Sicherheitslücke. Schlimmer noch, herkömmliche Tools zum Aufspüren von Lücken können den Meltdown-Angriff nicht erkennen, weil dieser nichts unerlaubtes tut, wie wir noch sehen werden. Vom lokalen Meltdown sind nicht nur Intel-Prozessoren betroffen, sondern auch die meisten Konkurrenz-Chips von AMD und ARM, mit Ausnahme der langsameren ARM-Kerne. Die meisten günstigen Smartphones verwenden nur die langsameren ARM-Kerne und sind daher vor Meltdown (und ebenso vor Spectre) gefeit, die meisten High-End- und Mid-Range-Smartphones sind hingegen ebenso betroffen wie PCs, Laptops und Server.

Bis die Meltdown-Malware-Welle richtig über uns hereinbricht, werden sicher noch einige Tage, wahrscheinlich sogar Wochen vergehen. Bis dahin ist aber Anwendern schonmal zu empfehlen, ihren persönlichen Datenschutz hochzufahren: Passwörter im Browser löschen, keine Browser-Plugins mit sensiblen Daten mehr nutzen, sich bei Websites nach der Nutzung auch wieder abmelden, insbesondere bei solchen Websites, wo einem Identitätsdiebstahl auch richtig weh tun kann, wie Facebook, Twitter und Google. Ein getrennter Browser fürs Online-Banking ist sowieso empfehlenswert, und die App-Liste auf dem Smartphone mal wieder auszumisten, hat auch noch nicht geschadet.

Genauso, wie ich fürchte, dass sich Meltdown via Javascript ausnutzen lässt, hoffe ich, dass sich Javascript-Interpreter und -Compiler so patchen lassen werden, dass das Ausnutzen nicht mehr möglich ist. Ein Whitepaper von ARM [Link entfernt] listet bereits Befehle auf, mit denen sich der (unter Android für die meisten Apps benutzte) Java-Compiler für ARM-Prozessoren erweitern lassen sollte. Wahrscheinlich sind die dort vorgestellten Technologien auch für andere Interpreter und Just-In-Time-Compiler nutzbar. Allerdings wird man sicher nicht auf einen Schlag alle Verwundbarkeiten finden, und so steht wahrscheinlich eine längere Update-Schleife bevor. Noch etwas schwieriger dürfte die Situation unter iOS sein, wo Apps direkt zu ARM-Code compiliert werden. Hier kommt künftig auf Apple einiges an Prüfaufgaben im App-Store zu, damit Meltdown nicht an ihnen vorbeigeschmuggelt wird.

Verheerende Performance-Jagd

Wie bereits geschrieben, sind so gut wie alle High-End-Prozessoren vom Meltdown-Angriff betroffen, und aktuelle Intel- und ARM-Prozessoren sowie wahrscheinlich auch AMD-Prozessoren zusätzlich von Spectre. Grund hierfür ist, dass die genannten High-End-Prozessoren beim Ausführen von Befehlen aus einem Programm manchmal auch Befehle "auf Verdacht" ausführen, selbst dann, wenn sie noch nicht sicher sind, dass diese wirklich benötigt werden. Dazu stelle man sich zunächst einen Wanderer vor, der regelmäßig von A nach B wandert. Mitten auf dem Weg ist eine Verzweigung, an der der Wanderer nach links oder nach rechts gehen kann. Wenn der Wanderer die letzten zwanzig Mal, die er an die Gabelung kam, immer nach links gegangen ist, dann wird man vermuten, dass er es auch beim einundzwanzigsten und zweiundzwanzigsten Mal so tun wird. Nichts anderes machen nun die spekulativen Prozessoren: Auch sie folgen bei der Programmabarbeitung den eingelaufenen Pfaden.

Wenn ein Programm also an einer Verzweigung ankommt, wo es je nach den zu verarbeitenden Daten nach "links" oder nach "rechts" weiterlaufen kann, das Programm aber bei den letzten fünfzig Ausführungen immer "links" weitergelaufen ist, dann werden die Einheiten des Prozessors annehmen, dass es auch beim einundfünzigsten Mal wieder nach links geht, und die Verarbeitung der Befehle in der linken Kette vornehmen. Stellt sich dann später heraus, dass es in Wirklichkeit dieses Mal nach rechts hätte gehen müssen, dann werden die falsch ausgeführten Befehle verworfen, und stattdessen wird die rechte Kette geladen. Das ist insgesamt aber schneller, als jedes Mal zu warten, bis die Entscheidung für "links" oder "rechts" sicher feststeht, so lange sich der Prozessor nicht allzu oft verspekuliert bzw. verrennt. Damit sie meist richtig raten, verfügen moderne Prozessoren über ausgeklügelte Sprungvorhersage-Einheiten, aber dazu später noch mehr.

Der Trick von Meltdown besteht nun darin, in der linken Kette just bei dem Durchlauf, in dem sich der Prozessor verrennt, weil es eigentlich nach rechts gegangen wäre, also just in diesem Durchlauf in der linken Kette den illegalen Datenzugriff unterzubringen. Da der Prozessor später die in der linken Kette ausgeführten Befehle wieder verwirft, kommt es trotz des illegalen Zugriffs nicht zum Programmabbruch. Allerdings nutzt das dem Angreifer noch nichts, denn auf die Daten aus der verworfenen Befehlsausführung kann er ja auch nicht zugreifen. Hier kommt der zweite Trick ins Spiel: In Abhängigkeit von den illegal beschafften Daten wird in der linken Kette das Laden von einem von mehreren möglichen legalen Speicherbereichen vom (langsamen) Hauptspeicher in den schnellen Zwischenspeicher im Prozessor (Cache) angestoßen. Und im Nachgang (nachdem sich der Prozessor zwischen links und rechts wieder sortiert hat) kann das Programm dann prüfen, welcher Speicherbereich geladen wurde - und damit auch herausfinden, was in den Daten stand, auf die es eigentlich gar nicht hätte zugreifen dürfen!

Bug-Potenzierung Spectre

Mit Spectre wird der Meltdown-Bug dann noch einmal potenziert. Denn die beteiligten Sicherheitsforscher konnten herausfinden, wie die Sprungvorhersage bei Intel-Prozessoren im Detail funktioniert - und sie anschließend gezielt durcheinander bringen. Stellen Sie sich dazu nochmal unseren armen Wanderer vor: Den Spectre-Forschern gelang es nicht nur, ihn zu verwirren, ob er dieses Mal nun links oder rechts gehen sollte. Vielmehr gelang es ihnen, ihn für eine gewisse Zeit so zu verwirren, dass er sich sogar zu einem von den Forschern vorgegebenen beliebigen anderen Punkt des Weges teleportierte, wo er dann eine Zeit lang wild herumirrte, bevor er endlich wieder zu Sinnen kam, seinen Fehler bemerkte, zur Gabelung zurücksprang und von dort aus nun den richtigen Weg nahm. Alle Aktionen aus dem vorangegangenen wilden Ausritt wurden beim Zurückspringen verworfen. Doch auch hier galt: Wurde während des Herumirrens gezielt das Laden von Daten in den Speicher angestoßen, dann hatte das Bestand. Und so ließ sich der Ausritt wieder zum Datensammeln zweckentfremden.

Schlimmer noch: Die Forscher konnten diese wilden Ausritte auch direkt im Betriebssystem-Kern provozieren - und zwar mit Programmcode, der lediglich mit normalen Nutzerrechten ausgeführt wurde, und anschließend ganz normale Betriebssystem-Funktionen aufrief. Da unmittelbar nach dem Ausritt alle fragwürdigen Aktionen (mit Ausnahme des Daten-Nachladens) auch wieder restlos storniert werden, gibt es wahrscheinlich auch keine Möglichkeit, solche Ausritte im Betriebssystem-Kern zumindest zu detektieren und anschließend als Sicherheitsverletzung zu protokollieren.

Normalerweise muss Schadsoftware, die die Prozessor-Verarbeitung auf Abwege schickt, extrem achtsam sein, dass sich auf dem Irrweg nicht doch irgendwo ein Problem verbirgt, das zum Absturz führt. Und zum Absturz kommt es ganz schnell: Dazu reicht eine Byte-Folge, die der Prozessor nicht als Befehl kennt, das Laden von Daten aus einem nicht vorhanden Speicherbereich, das Überschreiben eines geschützten Speicherbereichs oder dergleichen mehr. Doch für die spekulative Ausführung von Befehlen nach per Spectre verwirrter Sprungvorhersage gilt das alles nicht: Egal, wie sehr er sich auf dem spekulativen Pfad auch verirrt, dort Divisionen durch 0 durchführt oder allgemeine Schutzverletzungen auslöst: Sobald der Prozessor bemerkt, dass er sich verrannt hat, kehrt er ganz artig "auf den rechten Pfad" zurück, als ob nichts geschehen wäre. Lediglich die Speicherseiten, deren Laden zwischenzeitlich angestoßen wurde, verbleiben im Prozessor-Cache, und deren Anwesenheit kann das Programm des Angreifers dann wieder ganz in Ruhe prüfen. Entsprechend haben die Angreifer bei Spectre viel mehr Möglichkeiten, für ihre Datensammlung geeignete Code-Fragmente im Kernel zu finden, als sie geeignete Code-Fragmente für einen normalen Kontrollübernahme-Angriff finden können.

Bestätigt ist, dass von Spectre sowohl die meisten Intel- als auch die höherwertigen ARM-Prozessoren betroffen sind. Beide weisen auch den Fehler auf, dass die Sprungvorhersage-Einheit nicht zwischen Nutzer- und Betriebssystem-Code unterscheidet, und sich folglich zunächst im Nutzerland "trainieren" lässt, um dann im Betriebssystem-Kern auf Abwege geschickt zu werden. Immerhin lässt sich die Sprungvorhersage auf den ARM-Prozessoren an den Übergangsstellen zwischen Nutzer-Code und Kern gezielt abschalten - das wird aber die Performance in vielen Fällen merklich beeinträchtigen. Alternativ kann nach einem Google-Vorschlag an den Stellen im Betriebssystem-Kern, an denen freie Sprünge erfolgen, eine Methode verwendet werden, bei der (derzeitige) Prozessoren keine falsche Vorhersage treffen können, dafür der Sprung aber generell vergleichsweise langsam ausgeführt wird. Da solche freien Sprünge im Betriebssystem meist selten sind, ist die Performance-Einbuße - zumindest nach den Messungen von Google - eher gering. Ob der Google-Patch, der letztendlich die Code-Generierung des Compilers beeinflusst, zur Abwehr reicht, wird sich zeigen müssen.

Abwiegelung von Intel

Nicht sonderlich hilfreich ist, dass Intel die Bedeutung der Angriffe per Pressemitteilung herunterspielt, und behauptet, dass es sich weder um einen Fehler noch um eine Schwachstelle in Intel-Prozessoren handeln würde. Zwar hat Intel damit Recht, dass auch andere Hersteller betroffen sind, die gehen mit dem Problem aber erheblich offener um, wie insbesondere das verlinkte Whitepaper von ARM zeigt. Intels Abwiegelung bezüglich Spectre und Meltdown erinnert schon stark an die Abwiegelung von Volkswagen, als die Abschaltvorrichtungen für die Abgasreinigung bei Dieselautos ruchbar wurden. Insbesondere ist es zweifellos eine Schwachstelle, wenn normale Programme mit Daten aus Kern-Bereichen herumspekulieren können, oder gar die Sprungvorhersage von Kernel-Code beeinflussen können. Insbesondere von der ersten Schwachstelle ist AMD gar nicht betroffen, und auch ARM nur mit einem Teil ihrer Prozessoren.