Forscher von Bitdefender eine neue Schwachstelle () im Mechanismus der spekulativen Ausführung von Anweisungen moderner CPUs, die den Namen SWAPGS trägt, entsprechend dem Namen der Prozessoranweisung, die das Problem verursacht. Die Schwachstelle ermöglicht einem nicht privilegierten Angreifer, den Inhalt von Speicherbereichen des Kernels oder gestarteten virtuellen Maschinen zu bestimmen. Das Problem trifft Intel-Prozessoren (x86_64) sowie teilweise AMD-Prozessoren, bei denen der primäre Angriffsvektor nicht auftritt. Frühere Gegenmaßnahmen gegen die Schwachstellen Spectre und Meltdown bieten keinen Schutz vor dem SWAPGS-Angriff bei Verwendung von Intel-Prozessoren, doch für Linux, ChromeOS, Android und Windows wurden 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 Anweisungen verbleiben. Die Sprungvorhersageblöcke moderner CPUs zur Leistungssteigerung verwenden spekulative Ausführung bestimmter Anweisungen, die mit hoher Wahrscheinlichkeit ausgeführt werden, aber ohne auf die Berechnung aller Faktoren zu warten, die ihre Ausführung bestimmen (zum Beispiel, 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 bleiben die währenddessen verarbeiteten Daten im Prozessor-Cache und können mit Methoden zur Bestimmung des Cache-Inhalts über Seitenkanäle wiederhergestellt werden, die die Zugriffszeit auf gecachte und nicht gecachte Daten analysieren.
Das Besondere an dem neuen Angriff ist die Ausnutzung des Lecks, das während der spekulativen Ausführung der SWAPGS-Anweisung entsteht, die in Betriebssystemen verwendet wird, um den Wert des Registers GS beim Übergang von der Benutzer- zur Kernel-Ebene zu ersetzen (der im Benutzerraum verwendete GS-Wert wird durch den Wert ersetzt, der bei Operationen im Kernel verwendet wird). Im Linux-Kernel wird GS als Zeiger auf per_cpu verwendet, der für den Zugriff auf die Kerneldaten verwendet wird, während im Benutzerraum Zeiger auf TLS (Thread Local Storage) vorhanden sind.
Um einen doppelten Aufruf der SWAPGS-Anweisung bei wiederholtem Zugriff auf den Kernel aus dem Kernel-Raum oder wenn Code ausgeführt wird, der keinen Registerwechsel für GS erfordert, zu vermeiden, wird vor der Anweisung eine Überprüfung und ein bedingter Sprung durchgeführt. Der Mechanismus der spekulativen Ausführung springt vorzeitig zur Ausführung des Codes mit der SWAPGS-Anweisung, ohne auf das Ergebnis der Überprüfung zu warten, und wenn der gewählte Pfad nicht bestätigt wird, wird das Ergebnis verworfen. So kann es zu einer Situation kommen, in der spekulativ ein Pfad gewählt wird, der die Ausführung von SWAPGS nicht vorsieht, aber im Prozess 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 landen.
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 bei der tatsächlichen Ausführung verwendet wird, und das zweite umgekehrt, bei dem die SWAPGS-Anweisung spekulativ ausgeführt wird, obwohl sie tatsächlich nicht ausgeführt werden sollte. Für jedes Szenario sind zwei Varianten der Ausnutzung vorgesehen: Der Angreifer kann einen Wert an einer bestimmten Adresse im Kernel-Bereich bestimmen, und der Angreifer kann einen bestimmten Wert an zufälligen Adressen im Kernel suchen. Die Durchführung eines Angriffs benötigt viel Zeit, und um eine Datenleckage zu organisieren, kann es erforderlich sein, den Exploit mehrere Stunden lang auszuführen.
Im Linux-Kernel besteht das Problem durch Änderung der Logik des Aufrufs der SWAPGS-Anweisung (Sperren der spekulativen Ausführung), ähnlich der Behebung anderer Sicherheitsanfälligkeiten der Spectre v1-Klasse. Es wird angenommen, dass der hinzugefügte Schutz minimale Auswirkungen auf die Leistung typischer Arbeitslasten haben wird. Die Verzögerung tritt beim Wechsel zwischen Benutzer- und Kernel-Raum auf, was zu einer Verringerung der Leistung führen kann, beispielsweise bei intensiven Systemaufrufen aus einer Anwendung oder häufigen NMI- und Interrupt-Generierungen.
Die Behebung erfordert die Installation des Kernel-Updates sowohl im Hauptsystem als auch in den Gastumgebungen, gefolgt von einem Neustart des Systems. Um den Schutz in Linux zu deaktivieren, kann die Option „nospectre_v1“ verwendet werden, die auch die Maßnahmen zur Blockierung der SWAPGS-Schwachstelle deaktiviert. Die Behebung ist verfügbar als für den Linux-Kernel, der bereits in den Versionen , , 4.14.137, 4.9.188 und 4.4.188 enthalten ist. Updates für Linux-Distributionen sind derzeit nicht veröffentlicht worden (, , , , , ). In Windows wurde das Problem ohne unnötige öffentliche Bekanntgabe im behoben. Google hat die Behebung für den Kernel 4.19, der in ChromeOS geliefert wird, bereitgestellt. .
Laut Angaben von Forschern von Bitdefender wurde Intel bereits im August letzten Jahres über das Problem informiert. Das Problem sollte softwareseitig behoben werden, weshalb Entwickler von Microsoft, Google und dem Linux-Kernel an der koordinierten Entwicklung der Behebung beteiligt wurden. Alte Intel-Prozessoren, bis einschließlich Ivy Bridge, sind aufgrund der fehlenden Unterstützung der WRGSBASE-Anweisung, die im Exploit verwendet wird, erheblich schwerer angreifbar. ARM-, POWER-, SPARC-, MIPS- und RISC-V-Systeme sind von dem Problem nicht betroffen, da sie die SWAPGS-Anweisung nicht unterstützen.
Das Problem bedroht hauptsächlich Besitzer von Intel-Prozessoren -
auf AMD-Systemen konnte nur das zweite Angriffsszenario reproduziert werden, das sich auf die spekulative Verarbeitung des Grundwerts des GS-Registers beschränkt, was verwendet werden kann, um bestimmte Werte in zufälligen Speicherbereichen zu finden. Um diese Angriffsvariante zu blockieren, gibt es bestehende Methoden zum Schutz vor den Schwachstellen Spectre v1.
Quelle: opennet.ru
