Meltdown und Spectre in 3 Minuten

Dies ist die lokalisierte Version eines Blogbeitrags von Jon Masters, der ursprünglich in englischer Sprache verfasst wurde.

Aktuelle Presseberichte beschreiben eine neu entdeckte Form von Sicherheitsbedrohungen, wobei Angreifer grundlegende Funktionen moderner Mikroprozessoren (oder Chips) ausnutzen, die für den Betrieb unserer Computer, Tablets, Smartphones und anderer Geräte notwendig sind. Diese Angriffe, die unter den Namen „Meltdown" und „Spectre" bekannt sind, erregen momentan große Aufmerksamkeit. Die Menschen machen sich (zu Recht) Sorgen und natürlich ist es erstmal sehr wichtig, alle notwendigen Software-Updates zu installieren, die sorgfältig zusammengestellt und verfügbar gemacht wurden. Technologieführer, darunter auch Red Hat, arbeiten gemeinsam an einer Lösung für diese Sicherheitslücken und versuchen, das Risiko von potenziellen Attacken zu mindern.

Bei Red Hat haben wir im Rahmen standardmäßiger Sicherheitsembargos der Branche an schadensbegrenzenden Maßnahmen für potenzielle Angriffe gearbeitet, wobei wir kleine, zielgerichtete Teams nach dem Need-to-know-Prinzip (Kenntnis nur nach Bedarf) einsetzen, um Vorbereitungen im Vorfeld der Veröffentlichung zu treffen. Ich hatte das Glück, mitverantwortlich an unseren Bemühungen zur Schadensbegrenzung von Meltdown und Spectre teilzunehmen. Die Sicherheitslücken sind auch bekannt als die Varianten 1, 2 und 3 einer Familie ähnlicher Angriffe, die vom Google Project Zero in einem Blogbeitrag am 3. Januar veröffentlicht wurden. Im Zuge unserer Bemühungen haben wir Meltdown (Variante 3) in unseren Labs reproduziert und auch andere Varianten untersucht, wobei wir Seite an Seite mit vielen unserer zuverlässigen Hardware-Partnern an Abhilfemaßnahmen arbeiteten.

Obwohl wir diese Sicherheitslücken und die aktuelle Analyse der beitragenden Faktoren sowie die Gegenmaßnahmen zur Vermeidung potenzieller Auswirkungen gut verstehen, werden wir in dieser Situation weiterhin mit unseren Partnern, Kunden und Forschern zusammenarbeiten. Darüber hinaus möchten wir anderen helfen, diese komplexen Probleme zu verstehen, idealerweise mit einer Sprache und Begriffen, für die der Leser kein Fachwissen in Chip-Design benötigt. Für diejenigen, die sich in die technischen Details vertiefen möchten, sind die Original-Forschungsarbeiten und die zugehörigen Publikationen unter http://meltdownattack.com/ und http://spectreattack.com/ verfügbar. Man sollte aber nicht vergessen, dass viele der Personen, die an der Identifizierung dieser Sicherheitsbedrohungen beteiligt sind, einen umfangreichen Hintergrund in der akademischen Forschung über Computer-Architektur besitzen. Mindestens einer von ihnen promovierte im letzten Jahr in einem verwandten Bereich. Es ist also ganz normal, wenn es eine Weile dauert, sich in die technischen Details zu vertiefen – die Materie ist kompliziert und eingehend.

Lassen Sie uns damit beginnen, den Begriff der „spekulativen Ausführung" mithilfe einer alltäglichen Analogie besser zu verstehen.

Stellen wir uns vor, dass ein Stammkunde das gleiche Café aufsucht und jeden Morgen das gleiche koffeinhaltige Getränk bestellt. Mit der Zeit lernt der Kunde die Baristas kennen, die sich wiederum an seine Bestellung gewöhnen. Mit der Absicht, dem Kunden den besten Service zu bieten (und die Wartezeit zu verkürzen) entscheiden sich die Baristas eines Tages, die Bestellung des Kunden in dem Moment zusammenzustellen, in dem sie ihn durch die Tür kommen sehen. Eines Tages jedoch ändert der Kunde seine Bestellung. Jetzt muss der Barista den im Voraus zubereiteten Kaffee wegwerfen und ein neues Getränk machen, während der Kunde darauf wartet.

In einem weiteren Schritt können wir uns vorstellen, dass die Baristas den Namen des Kunden kennen und die Gewohnheit haben, diesen Namen mit einem Permanentmarker auf den Einwegbecher zu schreiben. Wenn sie sozusagen „spekulativ" das übliche Getränk anfertigen, dann schreiben sie den Namen des Kunden auf den Becher. Wenn der Kunde eine andere Bestellung aufgibt, dann werden der auf Vermutung zubereitete Becher und sein Inhalt weggeworfen. Dadurch werden aber die personenbezogenen Daten des Bechers für eine kurze Zeit für jeden, der beobachtet, sichtbar.

In diesem Café-Szenario findet eine Spekulation statt. Wenn der Kunde hereinkommt, weiß das Personal nicht mit Sicherheit, ob die Bestellung ein Latte oder ein Americano sein wird. Aufgrund von historischen Daten wissen sie aber, was der Kunde normalerweise bestellt und machen eine auf Erfahrung beruhende Annahme, um die Wartezeit zu verkürzen. In unserem täglichen Leben stellen wir oft ähnliche Spekulationen an, denn diese erweisen sich oft als zutreffend. Und unsere Computer verhalten sich auf gleiche Weise. Sie wenden eine Methode an, die als „spekulative Ausführung" bekannt ist, um bestimmte Prozesse abzuwickeln, bevor mit Sicherheit feststeht, dass diese Prozesse tatsächlich notwendig sind. Die grundsätzliche Annahme dahinter ist, dass diese Vermutungen oft zu Zeiteinsparungen führen werden.

Im Falle von Computern wird spekulative Ausführung eingesetzt, um zu entscheiden, was mit einem Test wie „falls A, Anweisung; sonst, Anweisung" zu tun ist. Wir nennen das Testbedingungen und der Code, der als Ergebnis ausgeführt wird, ist Teil einer bedingten Verzweigung. Eine Verzweigung ist einfach ein Abschnitt des Programms, das wir nach Auswertung der Bedingungen ausführen. Moderne Computerchips nutzen komplexe „Sprungvorhersagen", die mittels anspruchsvoller Algorithmen bestimmen, welches Ergebnis ein bedingter Test mit hoher Wahrscheinlichkeit haben wird. Diese Vorhersage wird während der Kalkulation des Tests generiert. In der Zwischenzeit führen sie auf spekulative Weise Code in dem Zweig aus, der am wahrscheinlichsten ausgeführt wird. Wenn sich die Vermutung als richtig herausstellt, scheint der Chip schneller zu laufen, als bis zur Beendigung des Tests zu erwarten gewesen wäre. Wenn die Schätzung falsch ist, muss der Chip spekulative Ergebnisse wegwerfen und den anderen Zweig ausführen. Sprungvorhersagen haben oft eine Vorhersagegenauigkeit von über 99 %.

Wie Sie sehen können, ist der potenzielle Leistungsvorteil eines Chips, der den korrekten Codezweig spekulativ ausführt, von großer Bedeutung. In der Tat ist die spekulative Ausführung eine der vielen Optimierungen, die in den letzten Jahrzehnten dazu beigetragen haben, unsere Computer dramatisch zu beschleunigen. Bei richtiger Implementierung ist der resultierende Leistungsvorteil beträchtlich. Die neu entdeckten Probleme entstanden aus Versuchen, Chips durch neues Design weiter zu optimieren, wobei angenommen wurde, dass der Spekulationsprozess eine Blackbox sei, die für Außenstehende (oder Bösewichte) völlig unsichtbar ist.

Die gängige Meinung in der Branche war, dass was auch immer während des Spekulationsprozesses („spekulatives Ausführungsfenster" genannt) geschah, entweder später bestätigt wurde und die Ergebnisse vom Programm verwendet wurden, oder es wurde nicht verwendet und vollständig verworfen. Es stellt sich jedoch heraus, dass Angreifer sehen können, was im Spekulationsfenster passiert ist, und demnach das System manipulieren können. Ein Angreifer kann auch das Verhalten von Sprungvorhersagen so steuern, dass bestimmte Codefolgen spekulativ ausgeführt werden, die unter normalen Umständen nie hätten ausgeführt werden sollen. Wir erwarten, dass diese Schwachstellen und andere ähnliche Fehler, die die spekulative Ausführung ausnutzen könnten, zu fundamentalen Änderungen in der Art und Weise führen, wie zukünftige Chips entworfen werden, sodass wir die spekulative Ausführung ohne Sicherheitsrisiken einsetzen können.

Lassen Sie uns etwas tiefer in die Angriffe eintauchen, beginnend mit Meltdown (Variante 3), das wegen seiner breiten Wirkung viel Aufmerksamkeit erhielt. Bei dieser Form des Angriffs wird der Chip dazu verleitet, vertrauliche Daten während eines Spekulationsfensters so zu laden, dass sie später von einem nicht autorisierten Angreifer ausgespäht werden können. Der Angriff beruht auf einer häufig verwendeten, branchenweiten Vorgehensweise, die das Laden von In-Memory-Daten von der Überprüfung von Berechtigungen trennt. Auch hier stützte sich die gängige Meinung der Branche auf die Annahme, dass der gesamte spekulative Ausführungsprozess unsichtbar sei, sodass die Trennung dieser Abläufe nicht als Risiko angesehen wurde.

Bei Meltdown veranlasst ein sorgfältig ausgearbeitetes Stück Code, dass ein Teil des Angriffscodes spekulativ ausgeführt wird. Dieser Code lädt einige vertrauliche Daten, auf die das Programm normalerweise keinen Zugriff hat. Weil dies spekulativ geschieht, findet die Berechtigungsprüfung für diesen Zugriff parallel statt (und schlägt bis zum Ende des Spekulationsfensters nicht fehl). In Folge werden privilegierte Daten in den speziellen internen Chipspeicher geladen, der als Cache bekannt ist. Dann wird eine sorgfältig konstruierte Codefolge verwendet, um andere Speicheroperationen basierend auf dem Wert der privilegierten Daten durchzuführen. Während die normalerweise beobachtbaren Ergebnisse dieser Operationen nach der Spekulation nicht sichtbar sind (die letztlich verworfen wird), kann eine als Cache-Seitenkanalanalyse bekannte Technik verwendet werden, um auf die vertraulichen Daten zurückzuschließen.

Die Abhilfemaßnahmen für Meltdown beinhalten eine Änderung des Speichermanagements zwischen Anwendungssoftware und Betriebssystem. Wir nutzen eine neue Technologie, die als KPTI (Kernel Page Table Isolation) bekannt ist. Sie trennt den Speicher so, dass vertrauliche Daten nicht in die internen Caches des Chips geladen werden können, während der Benutzercode läuft. Wenn jedes Mal zusätzliche Schritte unternommen werden, wenn die Anwendungssoftware das Betriebssystem auffordert, etwas in ihrem Namen zu tun (wir nennen das einen „Systemaufruf"), führt dies zu einer Leistungseinbuße. Der Grad der Leistungseinbuße entspricht in etwa der Häufigkeit, mit der eine Anwendung solche Betriebssystemdienste nutzen muss.

Der Spectre-Angriff besteht aus zwei Teilen. Der erste Teil (Variante 1) hat mit einem Verstoß gegen die „Grenzwertüberprüfung" (bounds check) zu tun. Wenn Code spekulativ ausgeführt wird, lädt der Chip wieder möglicherweise einige Daten, die später zur Lokalisierung eines zweiten Datenelements verwendet werden. Im Rahmen einer Leistungsoptimierung könnte der Chip versuchen, das zweite Datenelement spekulativ zu laden, bevor er validiert hat, dass das erste innerhalb eines definierten Wertebereichs liegt. Wenn dies geschieht, ist es möglich, eine spekulative Ausführung des Codes zu veranlassen und vertrauliche Daten in Caches des Systems einzulesen. Von hier können die Daten unter Verwendung eines Seitenkanalangriffs, ähnlich wie oben erörtert, extrahiert werden.

Die Abhilfemaßnahmen für den ersten Teil von Spectre beinhalten das Hinzufügen von sogenannten „Load Fences" im gesamten Kernel. Sie verhindern, dass die Spekulationshardware versucht, eine zweite Last (load) basierend auf einer ersten Last auszuführen. Diese erfordern kleine, triviale und nicht besonders leistungsbeeinflussende Änderungen im gesamten Kernel-Source-Code. Unser Toolchain-Team hat einige Werkzeuge entwickelt und mit Entwicklern zusammengearbeitet, um zu ermitteln, wo diese Load Fences liegen sollen.

Der zweite Teil von Spectre (Variante 2) ist in mancher Hinsicht der interessanteste. Es hat damit zu tun, die Hardware für Sprungvorhersagen zu „trainieren", spekulative Code-Elemente denjenigen vorzuziehen, die sie eigentlich ausführen sollte. Eine übliche Hardware-Optimierung besteht darin, das Verhalten einer gegebenen Verzweigungsauswahl auf den Speicherort des Verzweigungscodes selbst zu stützen. Leider ist die Art, in der dieser Speicherort abgelegt ist, zwischen einer Anwendung und dem Betriebssystem-Kernel nicht eindeutig. Dies ermöglicht es, den Vorhersagealgorithmus so zu beeinflussen, dass jeder beliebige Code eines Angreifers spekulativ ausgeführt wird. Durch sorgfältiges Auswählen eines „Gadgets" (vorhandener Code im Kernel, der Zugriff auf privilegierte Daten hat) kann der Angreifer sensible Daten in die Chip-Caches laden, wo er mittels der gleichen Art von Seitenkanalangriff wieder diese Daten extrahieren kann.

Eines der größten Probleme, das dieser zweite Teil von Spectre aufwirft, liegt in der potenziellen Ausnutzung der Grenze zwischen dem Betriebssystem-Kernel und einem Hypervisor oder zwischen verschiedenen virtuellen Maschinen, die auf derselben zugrunde liegenden Hardware laufen. Die Voraussage des Codezweiges kann von einer virtuellen Maschine so trainiert werden, dass privilegierter Code im Hypervisor (oder einer anderen virtuellen Maschineninstanz) auf vertrauliche Hypervisor-Daten zugreift, die über einen Seitenkanalangriff ausgelesen werden können. Dies stellt ein erhebliches Risiko für Private und Public Cloud-Umgebungen dar, auf denen nicht gepatchte Systeme betrieben werden.

Die Abhilfemaßnahmen für diesen zweiten Teil von Spectre beinhalten ein (selektives) Abschalten der Sprungvorhersage-Hardware durch das Betriebssystem, wenn ein Programm Systemaufruf- oder Hypervisor-Dienste anfordert. Auf diese Weise wird verhindert, dass jeglicher Versuch von bösartigem Code, die Sprungvorhersage zu trainieren, nicht in den Betriebssystem-Kernel, den Hypervisor oder zwischen nicht vertrauenswürdige virtuelle Maschinen, die auf demselben Server laufen, übertragen wird. Dieser Ansatz funktioniert gut, aber es kommt zu einer Leistungseinbuße, die nicht unbedeutend ist. Patches von Red Hat implementieren standardmäßig die Sicherheitsänderung und akzeptieren die Auswirkungen auf die Leistung. Wir haben jedoch Systemadministratoren auch die Möglichkeit eingeräumt, diese (und alle implementierten Einstellungen) ein- oder ausschalten zu können. Zusätzlich arbeiten wir kontinuierlich zusammen mit der Linux-Community an der Reduzierung der Leistungseinbußen, indem wir Alternativen zur Deaktivierung der Sprungvorhersage prüfen. Eine mögliche Alternative ist bekannt als „Retpoline", ein speziell konstruiertes Verfahren zur Ausführung von Betriebssystem-Kernel-Code, der ungültige Verzweigungsspekulationen verhindert.

Hoffentlich hat Ihnen dieser Beitrag ein wenig mehr Einblick in diese komplexen Angriffe gegeben. Ihre Umsetzung ist alles andere als trivial, Abhilfemaßnahmen sind möglich, und auch wenn einige Exploit-Beispiele für Meltdown (Variante 3) inzwischen online verfügbar sind, sind Patches über Updates von großen Anbietern wie Red Hat erhältlich. Mit der Zeit können zusätzliche, verwandte Sicherheitslücken entdeckt und entsprechender Beispielcode im Internet gepostet werden, um diese auszunutzen. Daher ist es wichtig, mit Sicherheitsupdates auf dem neusten Stand zu bleiben, sobald diese verfügbar sind.

Wir sollten nicht vergessen, dass wir nach der Entdeckung einer völlig neuen Klasse von Sicherheitslücken erst am Anfang stehen. Das kann bedeuten, dass sich im Laufe der Zeit Abhilfemaßnahmen und damit verbundene Ratschläge im Hinblick auf Best Practices ändern könnten. Wir werden weiterhin mit Branchenführern und den Open Source Communities zusammenarbeiten, um unsere Kunden vor diesen und anderen bekannten Schwachstellen zu schützen und Linux noch robuster gegen Angriffe wie Meltdown und Spectre zu machen. In den kommenden Monaten werden wir weitere Beiträge über diese Arbeit veröffentlichen und unsere Kunden hinsichtlich unserer Produkte auf dem Laufenden halten. Weitere Informationen erhalten Sie unter https://access.redhat.com/security/vulnerabilities/speculativeexecution

Highlights

Das könnte für Sie von Interesse sein