Eine Gruppe von Forschern der Vrije Universiteit Amsterdam hat das Kasper-Toolkit veröffentlicht, das dazu dient, im Linux-Kernel Codefragmente zu identifizieren, die zur Ausnutzung von Spectre-Sicherheitsanfälligkeiten verwendet werden können, die durch spekulative Codeausführung des Prozessors verursacht werden. Der Quellcode des Toolkits wird unter der Apache 2.0-Lizenz verteilt.
Es sei daran erinnert, dass für Angriffe wie Spectre v1, die es ermöglichen, den Inhalt des Speichers zu bestimmen, eine bestimmte Reihenfolge von Befehlen (sogenannten Gadgets) im privilegierten Code erforderlich ist, die zu einer spekulativen Ausführung von Anweisungen führt. Zum Zweck der Optimierung beginnt der Prozessor, solche Gadgets im spekulativen Modus auszuführen, erkennt später jedoch, dass die Vorhersage der Verzweigung nicht zutraf, und rollt die Operationen in ihren ursprünglichen Zustand zurück. Die im Verlauf der spekulativen Ausführung bearbeiteten Daten bleiben jedoch im Cache und in mikroarchitektonischen Puffern gespeichert und können mit verschiedenen Methoden zur Bestimmung von Restdaten über Seitenkanäle extrahiert werden.
Frühere verfügbare Tools zum Scannen von Gadgets für die Spectre-Sicherheitsanfälligkeit, die auf der Suche nach typischen Mustern basieren, zeigten eine sehr hohe Rate an Fehlalarmen und übersprangen dabei viele echte Gadgets (Experimente zeigten, dass 99 % der von diesen Tools identifizierten Gadgets nicht für Angriffe verwendet werden konnten und 33 % der funktionierenden Gadgets, die zu einem Angriff führen könnten, nicht erkannt wurden).
Um die Qualität der Identifizierung problematischer Gadgets zu verbessern, modelliert Kasper Sicherheitsanfälligkeiten, die ein Angreifer bei jeder Phase von Spectre-Angriffen nutzen kann – es werden Probleme simuliert, die es ermöglichen, Daten zu kontrollieren (zum Beispiel das Einfügen von Angreifer-Daten in mikroarchitektonische Strukturen, um die nachfolgende spekulative Ausführung durch LVI-Angriffe zu beeinflussen), auf vertrauliche Informationen zuzugreifen (zum Beispiel beim Übertreten von Puffergrenzen oder bei der Verwendung von Speicher nach dessen Freigabe) und Leaks vertraulicher Informationen zu organisieren (zum Beispiel durch Analyse des Zustands des Prozessor-Caches oder durch Anwendung der MDS-Methode).
Bei der Testphase wird der Kernel mit den Runtime-Bibliotheken von Kasper und Prüfungen, die auf der LLVM-Ebene arbeiten, verbunden. Im Prüfungsprozess erfolgt eine Emulation der spekulativen Ausführung von Code, die durch den Mechanismus des Checkpoint-Restore realisiert wird. Dieser führt speziell den missgebauten Zweig des Codes aus und rollt dann zum ursprünglichen Zustand vor dem Verzweigung zurück. Kasper versucht auch, verschiedene Software- und Hardwareanfälligkeiten zu modellieren, analysiert den Einfluss architektonischer und mikroarchitektonischer Effekte und führt Fuzzing-Tests auf mögliche Angreiferhandlungen durch. Für die Analyse von Ausführungsströmen wird der DataFlowSanitizer-Port für den Linux-Kernel verwendet, und für das Fuzzing-Testing kommt eine modifizierte Version des Pakets Syzkaller zum Einsatz.
Bei der Untersuchung des Linux-Kernels mit Kasper wurden 1379 zuvor unbekannte Gadgets identifiziert, die potenziell zu Datenlecks während der spekulativen Ausführung von Anweisungen führen können. Dabei wird festgestellt, dass nur ein Teil von ihnen möglicherweise reale Probleme darstellen könnte. Um zu demonstrieren, dass es sich um eine tatsächliche Gefahr und nicht nur um ein theoretisches Szenario handelt, wurde für einen der problematischen Codeabschnitte ein funktionierender Prototyp eines Exploits entwickelt, der zu einem Informationsleck aus dem Kernel-Speicher führt.
Quelle: opennet.ru
