Codeausführung in Windows-VBS-Enklave: Forscher brechen Isolation von SmartScreen-Komponente

Microsoft stuft die Schwachstelle als Rechteausweitung mit dem Schweregrad „Kritisch“ und einem CVSS-Wert von 7,8 ein. Nach Angaben von Microsoft wurde sie nicht ausgenutzt und war vor der Behebung nicht öffentlich bekannt; das Unternehmen gibt zudem an, denselben Fehler intern selbst gefunden zu haben. Die Arbeit von Doyensec entstand als Machbarkeitsnachweis im Labor, Angriffe in freier Wildbahn sind nicht beobachtet worden.

Eine VBS-Enklave ist laut Microsoft eine signierte Bibliothek, die ein normales Windows-Programm lädt, zur Laufzeit aber weder lesen noch verändern kann. Der Windows-Hypervisor hält den Speicher der Enklave in einer stärker vertrauenswürdigen Welt – VTL1 beziehungsweise Isolated User Mode –, auf die gewöhnlicher Code in der normalen Welt VTL0 keinen Zugriff hat. Genau deshalb ist das Ausführen angreifergewählten Codes in dieser Welt bemerkenswert.

Die angegriffene Enklave gehört zum erweiterten Phishing-Schutz von SmartScreen. Die Funktion überwacht eingegebenen oder eingefügten Text und warnt, wenn das Windows-Anmeldekennwort an einer unsicheren Stelle landet, etwa in Notepad oder auf einer Phishing-Seite. Damit das Passwort dabei nicht offengelegt wird, fängt Windows es bei der Anmeldung ab und legt es in gehashter Form in der Enklave ab, sodass spätere Eingaben dagegen geprüft werden können. Auf einem Windows-11-System lädt lsass.exe diese Enklave – der Prozess, der Anmeldeinformationen verarbeitet und als SYSTEM läuft.

Aus der Ferne funktioniert der Angriff nicht. Er setzt ein bereits auf dem Rechner laufendes Programm voraus, das die Enklave lädt und aufruft; bei SFAPE ist das LSASS. Microsofts eigene Bewertung deckt sich damit: lokaler Angriffsvektor, niedrige Rechte erforderlich, keine Nutzerinteraktion nötig. Es handelt sich also um einen Weg für Code, der bereits Fuß gefasst hat, in die benachbarte, stärker vertrauenswürdige Welt vorzudringen – nicht um einen Einstiegspunkt von außen.

Doyensec baute die Angriffskette aus einem kleinen Fehler schrittweise auf: Ein zweiter Aufruf der Initialize-Funktion der Enklave schreibt einen festen Vier-Byte-Fehlerwert an eine vom aufrufenden Programm kontrollierte Adresse – und überspringt dabei die Adressprüfung, die beim ersten Aufruf noch stattfindet. Die Forscher stellen klar, dass das für sich genommen schwach ist; von einem beliebigen Schreibzugriff zu sprechen, wäre „eine gewaltige Übertreibung“. An der richtigen Stelle platziert, verfälscht dieser eine Schreibvorgang jedoch den Wert, mit dem die Enklave ihren eigenen Speicher von dem des Hosts unterscheidet, womit ihre Sicherheitsprüfung wirkungslos wird. Anschließend löst ein Timing-Fehler in einer anderen Funktion ein kontrolliertes Löschen aus. Dieses verändert, wie die Enklave ein gespeichertes Objekt nachschlägt; der daraus resultierende Lese- und Schreibzugriff erlaubte es, die Tabelle zu ersetzen, die festlegt, welchen Code die Enklave ausführen darf.

Das Ergebnis ist angreifergewählter Code innerhalb der Enklave. Die Arbeit durchbrach die Isolation der Enklave; sie zeigte nicht, dass ein Nutzerpasswort ausgelesen oder entwendet wurde. Microsofts Sicherheitshinweis beschreibt die Auswirkung als Datenabfluss aus der Enklave beziehungsweise Codeausführung innerhalb der Enklave.

Der Fix steckt im kumulativen Update KB5124008 vom 8. September 2026 für Windows 11 in den Versionen 24H2 und 25H2. Ein Vergleich der alten und neuen Dateien durch Doyensec ergab, dass die gepatchte Enklave die Adresse nun vor dem ersten Schreibvorgang prüft und die Funktion verschärft, auf der der Timing-Fehler beruhte. Zusätzlich bringt das Update eine neue Richtlinie mit, die das Laden der alten, verwundbaren Enklave vollständig unterbindet. Eine separate Behelfslösung gibt es nicht – die Maßnahme besteht darin, das Update zu installieren.

Eine Lücke bleibt über diesen Fix hinaus bestehen: Windows führt keine allgemeine Sperrliste für verwundbare Enklaven, wie sie für verwundbare Treiber existiert, und die neue Richtlinie blockiert ausschließlich die alte SFAPE-Datei. Eine ältere Microsoft-Edge-Enklave mit einem ähnlichen Lese- und Schreibfehler – CVE-2023-36880 aus dem Jahr 2023 – darf nach Angaben von Doyensec weiterhin geladen werden. Ob das eine bewusste Entscheidung oder ein Versehen ist, bleibt offen. Relevant ist das, weil das Laden einer signierten, aber fehlerhaften Enklave eine bekannte Technik ist, gelegentlich „bring your own vulnerable enclave“ genannt: Frühere Untersuchungen von Akamai und Outflank nutzten sie, um Code und Daten vor Sicherheitswerkzeugen zu verbergen. Wird eine fehlerhafte Enklave blockiert, eine andere aber weiterhin zugelassen, bleibt dieser Trick verfügbar.