Die in Hardware gegossenen, eklatanten Sicherheitslücken Meltdown und Spectre dürften uns die nächsten Jahre beschäftigen. Da lohnt eine Bestandsaufnahme.

Das Jahr 2018 begann mit einem Super-GAU für die IT: Ein Großteil der in den letzten 15 Jahren verkauften Prozessoren enthält zwei eklatante Sicherheitslücken, die unsere Systeme angreifbar machen. Die auf die Namen Meltdown (Abbildung 1) und Spectre (Abbildung 2) getauften Schwachstellen betreffen vor allem CPUs des Marktführers Intel, aber auch jene von Apple, AMD, PowerPC und ARM64. Entwarnung gibt es dagegen für alle Raspberry-Pi-Modelle: Die dort verbauten Prozessoren weisen die Schwachstellen nicht auf.

Abbildung 1: Meltdown (Kernschmelze) ist ein passender Begriff: Viel schlimmer als Lücken im Silizium kann es nicht kommen. (Bild: Natascha Eibl, meltdownattack.com, CC0)

Abbildung 2: Das Schreckgespenst Spectre wird uns noch über viele Jahre begleiten. (Bild: Natascha Eibl, meltdownattack.com, CC0)

Wir tragen Mitschuld

Die Fehler in den Prozessoren resultieren aus dem Wettrennen um immer schnellere Rechner, an dem wir als Verbraucher nicht ganz unschuldig sind. Die Bezeichnung als schlimmster anzunehmender Unfall zieht seine Berechtigung aus der Tatsache, dass diese Sicherheitslücken uns noch sehr lange beschäftigen werden und sich nur mit einer neuen CPU-Generation gänzlich aus der Welt schaffen lassen – darüber dürften Jahre vergehen.

Auch die Kernel-Entwickler werden sich noch lange – wenn auch mit abnehmender Intensität – mit den Lücken befassen müssen, die sich auf PCs, Smartphones und in der Cloud auftun. Bei Smartphones und Tablets dürfen nur Besitzer aktuell noch unterstützter Geräte auf ein Schließen der Lücken hoffen, ältere Geräte bleiben ungeschützt.

Über die im Januar bekanntgewordenen Sicherheitslücken hinaus veröffentlichten Sicherheitsforscher am 14. Februar weitere Angriffsszenarien [1]. Die bisherigen Software-Patches decken diese neuen Angriffsvektoren zwar vermutlich mit ab, doch für Intel bedeutet das, dass die bisher entwickelten Änderungen an den CPU-Blaupausen Makulatur sind und die Ingenieure wieder zurück ans Reißbrett müssen. Damit rückt eine effektive Beseitigung der Lücken in noch weitere Ferne.

Intel mauert

Ein kurzer Abriss der Ereignisse soll hier zum besseren Verständnis nicht fehlen. Im Frühjahr und Sommer 2017 fanden zwei Forscherteams bei Google und an der Universität Graz alarmierende Hinweise, dass aus dem Speicher fast aller aktuellen CPUs flüchtige Daten wie Passwörter und andere vertrauliche Daten ausgelesen werden können. Das Vorgehen dabei erfordert vertieftes Wissen und passende Werkzeuge. Als potenzielle Täter kommen daher vor allem Regierungsorganisationen und gut aufgestellte Cyber-Kriminelle infrage.

Intel, ARM und AMD wurden von den Google-Forschern erstmals am 1. Juni 2017 über die Lücken informiert. Dass ein Unternehmen solche Informationen zunächst intern überprüfen muss, erscheint verständlich. Dass die Firma aber darüber hinaus ein halbes Jahr lang fehlerhafte CPUs verkaufte, ohne die Kunden zu informieren, wirkt äußerst fragwürdig und ist in den USA bereits Grundlage von gut 30 Einzel- und Sammelklagen.

Auch sonst vermittelt Intel in der Affäre immer wieder den Eindruck, dass dem Unternehmen mehr an den Aktienwerten liegt als an den Kunden. Besonders delikat erscheint in diesem Kontext die Tatsache, dass Intels Vorstandsvorsitzender Brian Krzanich in Kenntnis der Lücke, aber weit vor deren Bekanntgabe vorsorglich schon einmal einen Gutteil seiner 495?000 Intel-Aktien verkaufte. Er behielt lediglich jene Menge, die er nach den Firmenvorschriften zwingend halten muss, um seinen Job nicht zu verlieren.

Soweit die nackten Fakten. Zwar können sich Heimanwender damit trösten, dass Angreifer diese Lücken nur mit hohem Aufwand ausnutzen können, was hauptsächlich die Geheimnisse von Unternehmen und Institutionen in den Fokus des kriminellen Interesses rückt. Das macht die Angelegenheit aber um keinen Deut besser, vor allem nicht angesichts der unrühmlichen Rolle, die Intel in diesem Drama spielt: Hier bestimmten zunächst einmal Rechtsanwälte und Betriebswirte, wie das Unternehmen reagierte. Die Strategie: zunächst verschweigen, dann solange wie möglich leugnen, und schließlich abwiegeln, als leugnen nicht mehr möglich war.

Gleichzeitig ließ das Unternehmen seine Entwickler mit heißer Nadel neue Microcodes [2] stricken, die es dann prompt wieder zurückziehen musste. Für Linux lag die Hauptlast der Eindämmung bei den Kernel-Entwicklern. Sie wurden mitten im Entwicklungszyklus zu Linux 4.15 über die Feiertage am Jahresende von dem Dilemma überrascht, das anders als von Intel geplant schon vor dem 9. Januar publik wurde. Darauf brach bei den Kernel-Maintainern hektische Betriebsamkeit aus, als sie versuchten, die Folgen einer Katastrophe zu mildern, die sie selbst nicht zu verantworten hatten. Einige Entwickler brachte das an den Rand der Belastbarkeit.

Linus Torvalds, der Herr der Kernel, fand dann auch klare Worte für Intels Verhalten in der Sache und die untauglichen Reparaturversuche des Unternehmens [3]: Er bezeichnete Intels hastige Reparaturversuche als “absoluter Müll” und “völlig geisteskrank”. Auch Torvalds Generalissimo Greg Kroah-Hartman betonte, dies sei ein Paradebeispiel dafür, wie man nicht mit der Kernel-Entwicklergemeinde umgehen sollte. Die Lücken führten sogar dazu, dass mit /sys/devices/system/cpu/vulnerabilities/ (Abbildung 3) ein neues virtuelles Verzeichnis im Kernel-Verzeichnisbaum auftauchte.

Abbildung 3: Mit den Lücken erhielt der Kernel sogar ein neues Verzeichnis, das die jeweils umgesetzten Maßnahmen gegen die Lücken auflistet.

Spekulative Ausführung

Beide Lücken nutzen bestimmte Mechanismen in modernen Prozessor-Architekturen aus. Sie zielen insbesondere auf die Out-of-order-Execution [4] ab, die moderne Prozessoren beschleunigt (Abbildung 4). Sie führt spekulativ verschiedene Anweisungen aus, sodass der Prozessor die benötigte Anweisung bereits geladen hat, sobald er sie benötigt, und nicht erst langwierig auf den Speicher zurückgreifen muss.

Das Vorliegen dieser spekulativen Daten erlaubt es einem fähigen Angreifer, auf Benutzerebene auf den Kernel-Speicher zuzugreifen. Auf diesem Weg gelangt er an alle Daten, die die Maschine gerade im Speicher hält, einschließlich Passwörtern, Sicherheitszertifikaten und anderen sicherheitsrelevanten Daten.

Abbildung 4: Bei der Out-of-order-Befehlsausführung führt die CPU spekulativ mehrere mögliche Befehle aus, von denen sie dann einen tatsächlich umsetzt und die anderen verwirft. (Bild: Sputniktilt/Michael Kleine, commons.wikimedia.org, CC-BY-SA 2.0)

Zwar befindet sich theoretisch der Prozessor selbst bei einer Fehlspekulation in einem solchen Zustand, als hätte er die entsprechende Anweisung nie ausgeführt. Dennoch verändert die Out-of-order-Execution den Systemzustand aber an bestimmten Punkten, auch wenn die CPU das Ergebnis der spekulativen Ausführung verworfen hat. Über entsprechende Software bringt der Angreifer daher den attackierten Prozess dazu, von ihm eingebrachte Anweisungen spekulativ auszuführen.

Die Lücken ermöglichen drei verschiedene Angriffsszenarien, die man als Meltdown, Spectre v1 und Spectre v2 bezeichnet. Generell wurden Linux-Anwender früher und besser gegen Angriffe über diese Lücken geschützt als Windows-Nutzer. Das liegt nicht zuletzt daran, dass die Maßnahmen der Kernel-Entwickler sehr schnell bei den Anwendern ankommen.

Auch bei den Gegenmaßnahmen seitens der Chip-Hersteller sind Linuxer im Vorteil: Sie erhalten die in Microcode gegossenen Patches bei vielen Distributionen unmittelbar als installierbare Pakete. Windows-Anwender warten hier wesentlich länger, da die Hersteller die Patches erst an die OEMs übergeben, die sie dann erst an die jeweilige Hardware anpassen müssen und erst dann als BIOS- oder Firmware-Update an die Kunden weiterreichen können.

Der unter Linux als Paket installierte Microcode wird jeweils beim Start des Rechners geladen; das erspart auf Linux-Rechnern in solchen Fällen die Aktualisierung des BIOS. Beim Microcode selbst handelt es sich allerdings um unfreie Software, sodass Sie beispielsweise unter Debian vor der Installation erst einmal die Repositories contrib und nonfree freischalten müssen.

Klarheit geschaffen

Ein Papier von Intel vom 11. Februar schafft erstmals Klarheit darüber, welche Prozessoren neuen Microcode erhalten und wie es um den jeweiligen Entwicklungsstand steht [5]. Alle Angaben in dem Dokument beziehen sich auf Spectre 2: Das Schließen dieser Lücke setzt neben einem Patch im Kernel auch zwingend neuen Microcode von Intel voraus. Intel führt in dem Papier erstmals auch ältere CPUs auf, deren Veröffentlichung rund zehn Jahre zurückliegt. Demnach erhalten nun auch “Ivy Bridge”, “Sandy Bridge”, “Penryn”, “Wolfdale” und “Yorkfield” entsprechende Microcode-Updates.

Intel gab Anfang Februar eine neue Microcode-Version frei, die stabil allerdings zunächst nur für “Skylake”-Prozessoren vorlag. Zu Redaktionsschluss am 15. Februar war dieser Microcode noch nicht in den Linux-Distributionen angekommen; Versionen für weitere Prozessoren befanden sich zu diesem Zeitpunkt laut Intel noch im Beta-Test.

Der grundlegende Unterschied zwischen Spectre und Meltdown besteht darin, dass Spectre einen Prozess so manipuliert, dass er seine eigenen Daten enthüllt, während Meltdown privilegierten Speicher im Adressraum eines Prozesses auszulesen vermag, auf den selbst der Prozess normalerweise nicht zugreifen kann.

Meltdown

Meltdown [6] durchbricht die Sicherheitsbarrieren zwischen Userspace-Programmen und dem Kernel. Ein vom Angreifer präparierter Prozess veranlasst die CPU dazu, Daten spekulativ zu laden, und greift dann durch Aushebeln der Zugriffskontrolle direkt auf den Kernel-Bereich zu. Dazu lässt sich beispielsweise via Webbrowser ausgeführter, nicht vertrauenswürdiger Javascript-Code nutzen.

Das Problem beruht darauf, dass viele CPUs bei Speicherzugriffen während der spekulativen Ausführung auf ein Prüfen der Zugriffsrechte verzichten. Dadurch lassen sich Daten in den Cache laden, die eigentlich nicht im Zugriff liegen sollten. Es gibt zwar keine direkte Möglichkeit, die Daten von dort auszulesen. Es lassen sich aber Unterschiede in den Ausführungszeiten von Daten im Cache und außerhalb ausnutzen, um einzelne Bits im Speicher auszulesen. Durch Wiederholen der Prozedur kann entsprechender Schadcode den Speicher mit einer Rate von bis zu 1,5 KByte/s auslesen und auf dort gespeicherte Passwörter und andere sicherheitsrelevante Daten zugreifen.

Um diese Attacke zu unterbinden, trennen die Entwickler ab Kernel 4.15 die Page Tables, die bis dahin noch Kernel- und User-Space gemeinsam nutzten, in zwei völlig getrennte Sätze auf. Mit den entsprechenden Patches sieht ein Prozess also dank Kernel-Page-Table-Isolation (KPTI) nur noch den ihm zugedachten Speicherbereich, aber nicht mehr jenen des Betriebssystemkerns [7]. Das verhindert, dass ein unprivilegierter Prozess auf den Speicherbereich im Kernel-Space zugreifen kann.

AMD im Glück

Die Meltdown-Lücke plagt fast alle Intel-Prozessoren seit 1995, mit Ausnahme der Itanium-Architektur, der vor 2013 produzierten Atom-Prozessoren sowie einiger ARM64-Chips auf Basis des Cortex-A75. AMD-CPUs dagegen sind von Meltdown nicht betroffen. Der Linux-Kernel erhielt bereits zum Jahresende hin Meltdown-Patches, sodass ab Linux 4.15-rc7 vom 6. Januar ein guter Schutz bestand.

Die Entwickler portierten anschließend auf die LTS-Kernel 4.4 und 4.9 sowie auf Linux 4.14.12 zurück; Kernel 4.16 wird betroffene ARM64-CPUs absichern. Beim Android Common Kernel erhielten die Zweige 3.18, 4.4 und 4.9 entsprechende Patches. Der Kernel 4.15 bietet also grundsätzlich Schutz gegen Meltdown, der über die nächsten Kernel lediglich noch Verbesserungen am Code erhalten soll (Abbildung 5). Mit Kernel 4.15.4 vom 16.2. ist Spectre v1 nun ebenfalls geschlossen. Hier werden mit Kernel 4.16 aber noch weitere Patches folgen.

Abbildung 5: Der Spectre-Meltdown-Checker zeigt mit Kernel 4.15.0 nur noch Spectre v1 als verwundbar an. Meltdown und Spectre v2 sind geschlossen.

Spectre

Abwehrmaßnahmen gegen Spectre [8] verursachen in beiden Varianten der Lücke wesentlich mehr Aufwand als jene gegen Meltdown. Zudem betrifft Spectre auch AMD-Prozessoren sowie die PowerPC-Plattform. Gegen Spectre v2 gab es mit Kernel 4.15 erste Patches, die dann sukzessive weiter ausgebaut wurden und in Kernel 4.16 perfektioniert werden sollen.

Beide Varianten der Lücke lassen sich nur im Zusammenspiel von gepatchtem Kernel, angepasstem Compiler und Microcode von Intel oder AMD abdichten. Zudem gilt es, viele Tausend Anwendungen separat zu patchen, was wegen der besonderen Gefährdung bereits frühzeitig bei Firefox 57.0.4, Chrome 64 und anderen Webbrowsern erfolgte.

Googles Trampolin

Bei Linux kommt gegen Spectre ein Software-Konstrukt von Google zum Einsatz, dem die Entwickler den Namen Retpoline (“Return Trampoline”) gaben [9]. Damit lassen sich über eine Endlosschleife indirekte Zweige von der spekulativen Ausführung ausnehmen. Retpoline benötigt allerdings einen dafür angepassten Compiler, der mittlerweile mit GCC 7.3 bereitsteht.

Gleichzeitig veröffentlichte Intel einen neuen Microcode, der Spectre v2 mit den Maßnahmen Indirect Branch Prediction Barrier (IBPB), Single Thread Indirect Branch Predictors (STIBP) und Indirect Branch Restricted Speculation (IBRS) eindämmen soll. Hier setzte Torvalds’ Kritik an: Seiner Meinung nach handelt es sich dabei um “absoluten Müll” und einen “schmutzigen Hack”, der heftige Leistungseinbußen mit sich bringe. Intel gab ihm indirekt recht, indem es den fraglichen Microcode hastig wieder zurückzog und von dessen Verwendung abriet. Er führte bei “Broadwell”- und “Haswell”-CPUs zu Abstürzen und spontanen Reboots.

Die Kernel-Gemeinschaft setzt dagegen auf Retpoline, das ohne Leistungseinbußen auskommt. Als potenzielle Ergänzung gilt lediglich Intels IBPB, das als Barriere bei Kontextwechseln verhindern soll, dass die CPU bereits bekannte Branch-Targets erneut verwendet. Dazu müssen die CPU-Hersteller aber wiederum zunächst überarbeiteten Microcode verfügbar machen.

Spectre v1

Als letzte der drei Lücken müssen sich die Kernel-Entwickler Spectre v2 vornehmen. Am 4. Februar wurden erste grundlegende Patches zur Eindämmung von Spectre v1 eingereicht, die mittlerweile bereits in Kernel 4.15.4 einflossen. Weitere Verbesserungen dürften für den Anfang April erwarteten Kernel 4.16 und die folgenden Kernel-Versionen folgen. Diese Codeflicken betreffen sowohl die x86-Plattform als auch ARM64.

Unmittelbare Folgen

Bei sämtlichen betroffenen Prozessoren reduzieren die Eindämmungsmaßnahmen die Rechenleistung, insbesondere jene gegen Meltdown. Während die Einbußen bei Desktop-Rechnern üblicherweise die Marke von fünf Prozent nicht überschreiten, muss man bei Servern je nach Einsatzprofil mit einem Leistungsverlust von 30 Prozent und mehr rechnen.

Die jeweiligen Auswirkungen hängen durch die Trennung der Page-Tables stark von der Anzahl der Systemaufrufe und der Kontextwechsel zwischen Userspace und Kernel ab. Sowohl Intel als auch die Kernel-Entwickler gehen davon aus, die Höhe der Verluste in nächster Zeit noch reduzieren zu können.

Fazit und Ausblick

Als Linux-Anwender begegnen Sie Meltdown und Spectre am besten mit Aktualität: Entweder Linux 4.15.x oder die rückgepatchten LTS-Kernel der Serien 4.4, 4.9 und 4.14 sind hier das Maß der Dinge. Einer Distribution, die hier nicht auf dem Laufenden bleibt, sollten Sie den Laufpass geben. Windows-Nutzer haben hier das Nachsehen, da bei ihnen alle Maßnahmen zeitverzögert ankommen. BSD erhielt am 17. Februar erste Patches, die denen unter Linux gleichen.

Das grundlegende Problem steckt im Silizium der Prozessoren und lässt sich auch nur dort beheben. Schon ein neues Stepping einer CPU dauert bis zu drei Jahre und kostet Millionen; zudem ist fraglich, ob sich überhaupt alle nötigen Gegenmaßnahmen in einem einzigen Stepping unterbringen lassen. Eine weitere Schwierigkeit besteht darin, die Schwachstellen zu beheben, ohne dabei an anderer Stelle neue Fehler herbeizuführen.

Vorsichtige Schätzungen gehen davon aus, dass diese Lücken auch in einem Jahrzehnt noch im Hintergrund lauern könnten. Dafür spricht auch, dass kurz vor Drucklegung die neuen Angriffsvektoren MeltdownPrime und SpectrePrime bekannt wurden [10], die weiterer Änderungen am Silizium bedürfen – es dürften nicht die letzten sein.

Bislang gibt es in der freien Wildbahn wohl noch keine Schadsoftware, die Meltdown und Spectre tatsächlich ausnutzen kann. Das ist aber mehr der Komplexität der Angriffsvektoren geschuldet als einem Desinteresse krimineller Programmierer: Es taucht bereits erste, glücklicherweise aber noch ineffiziente Malware auf, die sich an der Ausnutzung der Lücken versucht.

Die wohl komplettesten Informationen zu Meltdown und Spectre haben die Entdecker der Lücken in Googles Projekt Zero [11] veröffentlicht. Den aktuellen Stand des Schutzes Ihrer eigenen Hardware können Sie mit einem Skript überprüfen, das Sie von Github herunterladen [12] und als Root ausführen (Listing 1). Unter den aktuellsten Debian- und Ubuntu-Versionen installieren Sie es über das Paket spectre-meltdown-checker direkt aus den Repositories. 

$ wget meltdown.ovh -O spectre-meltdown-check
$ chmod u+x spectre-meltdown-checker.sh
$ sudo ./spectre-meltdown-checher.sh