Forscher von Bitdefender eine neue Schwachstelle () im Mechanismus der spekulativen Ausführung moderner CPUs, die den Namen SWAPGS trägt, entsprechend der Prozessoranweisung, die das Problem verursacht. Die Schwachstelle ermöglicht es einem nicht privilegierten Angreifer, den Inhalt von Speicherbereichen des Kernels oder von laufenden virtuellen Maschinen zu bestimmen. Das Problem in Intel-Prozessoren (x86_64) und teilweise in AMD-Prozessoren, bei denen der grundlegende Angriffsvektor nicht auftritt. Frühere Methoden zur Bekämpfung der Schwachstellen Spectre und Meltdown schützen nicht vor dem SWAPGS-Angriff bei der Verwendung von Intel-Prozessoren, jedoch wurden für Linux, ChromeOS, Android und Windows bereits Patches vorgeschlagen.
Die Schwachstelle gehört zur Klasse Spectre v1 und basiert auf der Idee, Daten aus dem Prozessor-Cache wiederherzustellen, die nach der spekulativen Ausführung von Instruktionen zurückbleiben. Die Branch Prediction-Module moderner CPUs verwenden das spekulative Ausführen bestimmter Instruktionen, von denen wahrscheinlich angenommen wird, dass sie ausgeführt werden, ohne auf die Berechnung aller Faktoren zu warten, die ihre Ausführung bestimmen (z. B. wenn die Bedingungen für den Sprung oder die Zugriffsparameter noch nicht berechnet wurden). Wenn die Vorhersage nicht bestätigt wird, verwirft der Prozessor das Ergebnis der spekulativen Ausführung, jedoch können die während dieses Prozesses verarbeiteten Daten im Prozessor-Cache verbleiben und mithilfe von Techniken zur Bestimmung des Cache-Inhalts durch Seitenkanäle wiederhergestellt werden, die die Zugriffszeit auf gecachte und nicht gecachte Daten analysieren.
Eine Besonderheit des neuen Angriffs liegt in der Nutzung einer Leckage, die während der spekulativen Ausführung der SWAPGS-Anweisung auftritt. Diese wird in Betriebssystemen verwendet, um den GS-Registerwert beim Wechsel von Benutzer- in Kernelmodus zu ersetzen (der im Benutzermodus verwendete GS-Wert wird durch den im Kernelbetrieb verwendeten Wert ersetzt). In dem Linux-Kernel speichert GS einen per_cpu-Zeiger, der für den Zugriff auf die Kernel-Daten verwendet wird, während im Benutzermodus Zeiger auf TLS (Thread Local Storage) gespeichert sind.
Um einen doppelten Aufruf der SWAPGS-Anweisung zu vermeiden, wenn erneut auf den Kernel aus dem Kernelraum zugegriffen wird oder wenn Code ausgeführt wird, der keinen Wechsel des GS-Registers erfordert, wird vor der Anweisung eine Überprüfung und ein bedingter Sprung durchgeführt. Der Mechanismus der spekulativen Ausführung wechselt vorzeitig zur Ausführung des Codes mit der SWAPGS-Anweisung, ohne auf das Ergebnis der Überprüfung zu warten. Wenn der gewählte Pfad dann nicht bestätigt wird, wird das Ergebnis verworfen. In diesem Zusammenhang kann es dazu kommen, dass spekulativ ein Pfad gewählt wird, der die Ausführung von SWAPGS nicht vorsieht, jedoch während der spekulativen Ausführung der Wert des GS-Registers durch die SWAPGS-Anweisung geändert wird und in abhängigen Speicheroperationen verwendet wird, die im CPU-Cache verbleiben.
Forscher haben zwei Angriffszenarien vorgeschlagen, für die Prototypen von Exploits entwickelt wurden. Das erste Szenario basiert auf der Situation, in der die SWAPGS-Anweisung nicht spekulativ ausgeführt wird, obwohl sie während der tatsächlichen Ausführung verwendet wird; das zweite dagegen, bei dem die SWAPGS-Anweisung spekulativ ausgeführt wird, obwohl sie dies tatsächlich nicht sollte. Für jedes Szenario sind zwei Ausnutzungsvarianten vorgesehen: Der Angreifer kann einen Wert an einer bestimmten Adresse im Kernel bestimmen und der Angreifer kann einen bestimmten Wert an zufälligen Adressen im Kernel suchen. Der Angriff benötigt viel Zeit, und um eine Leckage zu organisieren, kann es notwendig sein, den Exploit über mehrere Stunden auszuführen.
Im Linux-Kernel besteht ein Problem Durch die Änderung der Aufruflogik der SWAPGS-Anweisung (Blockierung der spekulativen Ausführung) erfolgt eine Anpassung analog zu den Korrekturen anderer Schwachstellen der Spectre v1-Klasse. Es wird angenommen, dass der hinzugefügte Schutz die Leistung typischer Arbeitslasten nur minimal beeinträchtigt. Die Verzögerung tritt beim Wechsel zwischen Benutzer- und Kernelraum auf, was zu einer Leistungsminderung führen kann, beispielsweise bei intensiver Durchführung von Systemaufrufen aus Anwendungen oder häufiger Erzeugung von NMI und Interrupts.
Die Korrektur erfordert die Installation eines Kernel-Updates sowohl auf dem Hauptsystem als auch in den Gastsystemen, gefolgt von einem Neustart des Systems. Um den Schutz in Linux zu deaktivieren, kann die Option „nospectre_v1“ verwendet werden, die ebenfalls die Maßnahmen zur Blockierung der SWAPGS-Schwachstelle ausschaltet. Der Fix ist verfügbar als für den Linux-Kernel, der bereits in die Versionen , , 4.14.137, 4.9.188 und 4.4.188 integriert ist. Updates für Linux-Distributionen wurden bisher nicht veröffentlicht (, , , , , ). Das Problem wurde in Windows ohne große Ankündigung in behoben. Google liefert den Fix für den Kernel 4.19, der in ChromeOS bereitgestellt wird und .
Laut Forschern von Bitdefender wurde Intel bereits im August letzten Jahres über das Problem informiert. Die Lösung sollte softwaretechnisch erfolgen, wozu Entwickler von Microsoft, Google und dem Linux-Kernel koordiniert an der Entwicklung eines Fixes beteiligt wurden. Ältere Intel-Prozessoren, die vor Ivy Bridge erschienen, sind aufgrund des Fehlens der WRGSBASE-Instruktion, die im Exploit verwendet wird, deutlich schwieriger anzugreifen. Systeme mit ARM, POWER, SPARC, MIPS und RISC-V sind von dem Problem nicht betroffen, da sie die SWAPGS-Instruktion nicht unterstützen.
Das Problem betrifft vor allem Besitzer von Intel-Prozessoren —
auf AMD-Systemen konnte nur das zweite Angriffsszenario reproduziert werden, das sich auf die spekulative Verarbeitung des Grundwertes des Registers GS beschränkt, was zur Suche nach bestimmten Werten in zufälligen Speicherbereichen verwendet werden kann. Um diese Angriffsvariante zu blockieren, gibt es bereits Methoden zum Schutz gegen die Spectre v1.-Schwächen.
Quelle: opennet.ru
