Was Entwickler über Spectre und Meltdown wissen müssen

Sicherheitsrisiko CPU: Wie gefährlich sind Spectre und Meltdown wirklich?
Kommentare

Spectre und Meltdown sind die wohlklingenden Namen der neusten Schwachstellen in der IT-Sicherheit. Wie gefährlich sind die Sicherheitslücken wirklich und was müssen Entwickler jetzt darüber wissen?

Es gibt mal wieder neue Schwachstellen, und auch schöne Namen dazu: Meltdown und Spectre. So weit, so gut. Oder besser schlecht.

Das hatten wir ja schon öfter. Also sowohl Schwachstellen als auch marketingfördernde Namen. Eines ist diesmal aber neu: Die Schwachstellen befinden sich nicht in der Software, sondern in der Hardware. Konkret: Der CPU. Und nicht nur in einer, sondern gleich in mehreren; nicht nur von einem Hersteller, sondern von dreien. Als Hardwareproblem betreffen diese Schwachstellen nicht nur ein Programm oder ein System, sondern alle, die diese CPUs nutzen.

Sie erkennen das Problem? Viel schlimmer kann es eigentlich nicht mehr werden. Der einzige positive Punkt, den ich zur Zeit sehe: Über die Schwachstellen können „nur“ Daten ausgespäht werden, Code lässt sich hingegen nicht einschleusen. Aber auch das ist je nach Umgebung schon fatal genug.

Was ist genau los?

Die CPU-Hersteller sind bei ihren Beschreibungen ziemlich wage, aber inzwischen gibt es Informationen über die Schwachstellen aus erster Hand: Von Google, dessen Project Zero die Schwachstellen entdeckt hat und sie detailliert beschreibt. Und da sind sie nicht die einzigen, aber dazu gleich mehr.

Eigentlich sollten die Schwachstellen bis zum 9. Januar geheim bleiben, aber nach ersten Presseberichten hat Google sich zur vorgezogenen Veröffentlichung der Informationen entschlossen. Ursache der Schwachstellen ist die sog. „Speculative execution“, die zur Optimierung der Performance eingesetzt wird. Dabei wird versucht, die nächsten Berechnungen vorherzusagen und auszuführen, bevor sie benötigt werden.

Werden die Berechnungen dann benötigt, steht das Ergebnis sofort zur Verfügung, der Ablauf der Berechnungen wird beschleunigt. Wenn nicht, wird ganz normal weitergearbeitet. Ein bösartiges Programm kann diese Technik nutzen, um sich Zugriff auf eigentlich unzugängliche Speicherbereiche zu verschaffen. Je nach Umgebung können z. B. Passwörter, private Krypto-Schlüssel oder andere vertrauliche Informationen ausgespäht werden. Auf virtuellen Maschinen betrifft das unter Umständen auch physikalische Speicher der Host-Maschinen und darüber den Speicher einer anderen VM auf dem gleichen Host.

Betroffen sind CPUs von Intel, AMD und ARM sowie die Geräte, in denen sie verbaut sind, und die Systeme und Programme, die auf ihnen laufen. Die Schwachstellen können nur ausgenutzt werden, wenn Schadcode auf einem Rechner läuft. Dann sind je nach Umgebung drei Angriffe möglich, die alle einem Prozess unbefugte Speicherzugriffe erlauben.

Wie schon erwähnt versuchen die CPUs, die nächsten auszuführenden Befehle vorauszusagen. Treffen die dabei gemachten Annahmen zu, wird die Ausführung des Codes weiter fortgesetzt. Stimmen sie nicht, wird die spekulative Ausführung verworfen und mit den korrekten Werten weitergerechnet. Dabei kann es vorkommen, dass beim Wiederherstellen des korrekten CPU-Status durch Seiteneffekte Informationen preisgegeben werden.

Konkret sind folgende drei Varianten bekannt:

  1. CVE-2017-5753: „Bounds Check Bypass“
  2. CVE-2017-5715: „Branch Target Injection“
  3. CVE-2017-5754: „Rogue Data Cache Load“

Bevor die Schwachstellen von Google Project Zero veröffentlicht wurden, wurden sie parallel von einer Reihe weitere Forscher entdeckt und beschrieben, die ihnen schöne Namen gaben: „Spectre“ (PDF) für Variante 1 und 2 und „Meltdown“ (PDF, weitere Beschreibung) für Variante 3.

Ist das nur Theorie oder gibt es auch Angriffe?

Bisher sind keine Angriffe „in the wild“ bekannt. Von Googles Project Zero wurden die folgenden vier „Proof-of-Concepts“ (PoC) zur Demonstration der Schwachstellen entwickelt:

  1. Ein PoC, der die Grundprinzipien von Variante 1 auf den Prozessoren Intel Haswell Xeon, AMD FX, AMD PRO und ARM Cortex A57 demonstriert. Der PoC testet nur, ob Daten innerhalb des gleichen Prozesses gelesen werden können, es werden keine Privilegiengrenzen überschritten.
  2. Ein PoC für Variante 1, der einem normalen Benutzer auf einem Linux-Kernel auf einer Intel Haswell Xeon CPU beliebige Leseoperationen in einem 4 GiB-Bereich des virtuellen Kernel Speichers erlaubt. Nach ca. 4 Sekunden Startzeit kann der Speicher mit einer Rate von ca. 2.000 Byte pro Sekunde gelesen werden. Ist der BPF JIT eingeschaltet (was per Default nicht der Fall ist), funktioniert der PoC auch mit AMD PRO CPUs.
  3. Ein PoC für Variante 2, der mit Root-Rechten in einer VM auf einer Intel Haswell Xeon CPU läuft und Kernelspeicher des Hosts mit einer Geschwindigkeit von ca. 1.500 Bytes/Sekunde lesen kann. Zuvor sind einige Vorbereitungen nötig, die zwischen 10 und 30 Minuten dauern.
  4. Ein PoC für Variante 3, der unter bestimmten Voraussetzungen auf einer Intel Haswell Xeon CPU mit normalen Benutzer-Rechten Kernel-Speicher lesen kann.

Betroffene CPUs

Von Project Zero wurden die folgenden CPUs getestet:

  • Intel Xeon E5-1650 v3 @ 3.50GHz (genannt „Intel Haswell Xeon CPU“)
  • AMD FX-8320 Eight-Core Processor (genannt „AMD FX CPU“)
  • AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (genannt „AMD PRO CPU“)
  • ARM Cortex A57 Core in einem Google Nexus 5x (genannt „ARM Cortex A57“)

Darüber hinaus sind sehr wahrscheinlich weitere CPUs betroffen. Die Hersteller haben dazu bisher folgende Stellungnahmen veröffentlicht:

  • Intel hält den Ball in seiner Presseerklärung möglichst flach und verweist u. A. darauf, dass ja auch andere Hersteller betroffen sind. Interessant ist, dass der CEO von Intel Ende November so viele seiner Intel-Aktien verkauft hat, dass er nun nur noch exakt die minimal nötige Anzahl besitzt, die er laut Satzung als CEO besitzen muss.
  • AMD spielt das Problem ebenfalls herunter: Es gibt ja bisher keine Angriffe „in the wild“, Variante 1 wird durch Software-Updates behoben, Variante 2 ist wohl nicht ausnutzbar, und von Variante 3 ist man gar nicht betroffen.
  • ARM hat sich sehr ausführlich geäußert und alle betroffenen CPUs aufgelistet (dafür ist die Website zeitweise nur schwer zu erreichen).

Betroffene Systeme und Anwendungen

  • Android: Die Schwachstellen werden durch das Security-Update vom Januar 2018 behoben.
  • Linux: Mit KAISER („Kernel Address Isolation to have Side-channels Efficiently Removed“) steht eine neue Schutzmaßnahme für den Kernel zur Verfügung (Beschreibung).
  • MacOS: Die Schwachstellen wurden bereits in Version 10.13.2 behoben und weitere Patches werden in Version 10.13.3 enthalten sein.
  • Windows: Am 3.1. wurde ein Windows-Update veröffentlicht, dass die Schwachstellen behebt. Vermutlich ist es das Update, das eigentlich am kommenden Patchday am 9.1. veröffentlicht worden wäre. Leider gibt es von Microsoft ja keine Security Bulletins mehr, und Blogposts zu diesem Update habe ich auch nicht gefunden. Aber gut, dass wir nicht darüber geredet haben, das könnte ja womöglich die Benutzer verunsichern! Das Update führt zu Problemen mit einigen Antivirus-Produkten, die nicht unterstützte Aufrufe in den Kernel-Speicher verwenden, die nun zu einem Absturz führen. Das Problem lässt sich leicht lösen: Programme, die nicht unterstützte Aufrufe verwenden, sollte man ganz einfach nicht unterstützen. Vor allem keine Sicherheitsprogramme – wo kommen wir denn da hin, wenn Programme, die der Sicherheit dienen, solche unsicheren Methoden verwenden?
  • Browser: Google hat für Chrome die „Site Isolation“ eingeführt, die primär Universal XSS verhindern soll, aber auch Angriffe über die CPU-Schwachstellen verhindert. Weitere Schutzmaßnahmen sind geplant. Mozilla arbeitet an Schutzmaßnahmen, konkret wurde zunächst die Genauigkeit der Zeitmessung in Firefox herabgesetzt, da alle Angriffe Timing-basiert sind und eine genaue Zeitmessung erfordern.
  • Cloud: Updates für Amazon EC2Microsoft Azure und Googles Cloud-Produkte wurden bzw. werden installiert, was teilweise zu Reboots führt.

Wie gefährlich ist das?

Das kommt ganz darauf an, worum es geht. Sowohl Meltdown als auch Spectre lassen sich nur ausnutzen, wenn der Angreifer Code auf dem angegriffenen Rechnern ausführen kann. Was dann passieren kann, zeigt das Video eines Meltdown-Angriffs eindrucksvoll. Gefährdet sind also alle Rechner, auf denen ein Angreifer Code ausführen kann. Und das sind eigentlich alle.

In der Cloud kann es bösartige Benutzer geben, auf Webservern teilweise ebenso, auf anderen Server kann ein Angreifer nach der Kompromittierung des Servers über diese Schwachstellen deutlich größeren Schaden anrichten als ohne sie möglich wäre. Auf Client-Rechnern kann Schadsoftware laufen, oder eine Webseite enthält entsprechenden JavaScript-basierten Schadcode, oder, oder,  oder ….

Wenn ein Angriff stattfindet, kommt es danach darauf an, was der Angreifer ausspähen kann. Auf einem Webserver und in der Cloud wäre der Worst Case wohl das Ausspähen des privaten Schlüssels für das HTTPS-Zertifikat. Auf einem Client wären es wohl Zugangsdaten oder ebenfalls private Schlüssel, z.B. für das Zertifikat, mit dem ein Entwickler seinen Code signiert oder ein Admin seine SSH-Verbindung absichert. Oder auch die Zugangsdaten zu Social Networks, Webshops, Onlinebanking, …

Irgend welche Daten, die nicht in fremde Hände fallen dürfen, werden Sie sicher auf Ihrem Rechner haben. Also sollten Sie aufpassen, kein Opfer von Meltdown oder Spectre zu werden.

Was ist zu tun?

Wie immer gilt: Ruhe bewahren und Updates installieren.

In der Cloud haben die Betreiber ihren Teil der Aufgaben meist schon erledigt, jetzt müssen Sie ggf. noch Updates Ihrer Systeme und Anwendungen installieren. Das gleiche gilt auf allen Hardware-basierten Rechnern, egal ob Server, Desktop, Notebook, Tablet, Smartphone oder ähnliches. Wobei vermutlich mal wieder die Android-Nutzer den Schwarzen Peter bekommen werden, weil es für viele Android-Geräte keine Updates mehr gibt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -