Kürzlich wurden Informationen über eine Sicherheitslücke veröffentlicht , die Cloud-Server gefährdet. Diese Sicherheitslücke ermöglicht Angreifern die vollständige Kontrolle über die physischen Server – ein Albtraumszenario für Cloud-Infrastrukturanbieter.
Zapscape, registriert unter der Kennung CVE-2026-64561, ist eine kritische Sicherheitslücke im Linux-KVM-Hypervisor. Sie legt ein Risiko offen, das viele Plattformen unbeabsichtigt eingehen, indem sie verschachtelte Virtualisierung aktivieren. Diese Sicherheitslücke ermöglicht es einem Angreifer mit Kernel-Rechten in einer virtuellen Maschine (L1), Code mit Root-Rechten auf dem Hostsystem (L0) auszuführen und so die Isolation virtualisierter Umgebungen aufzuheben.
Zapscape wird als schwerwiegende Bedrohung eingestuft, da es nicht nur das Entkommen aus der virtuellen Maschine ermöglicht, sondern auch eine lokale Möglichkeit zur Rechteausweitung für Host-Benutzer eröffnet, die Schreibberechtigungen auf dem Gerät /dev/kvm besitzen.
Obwohl Organisationen wie Red Hat die Schwachstelle mit einem CVSS-Score von 7.0 bewertet haben, wobei der Fokus auf Instabilität und Dienstverweigerung liegt, zeigt der öffentliche Proof of Concept (PoC) ein viel zerstörerischeres Ausmaß: die Erstellung einer beliebigen Datei direkt im Stammverzeichnis des Hosts.
Chaos in der Speicherverwaltungseinheit
Die Funktionsweise von Zapscape ist in der Speichermanagementeinheit (MMU) von KVM verborgen und hängt davon ab, wie der Hypervisor Seitentabellen handhabt, wenn ein Gastsystem (L1) als Hypervisor für ein anderes Sub-Gastsystem (L2) fungiert. Das Problem liegt in einem logischen Reihenfolgefehler bei der Seitenfehlerbehandlung. Im Kernel-Code wurde die Prüfung auf ein veraltetes Stammverzeichnis vor der Seitenabruffunktion anstatt danach ausgeführt.
Diese fehlerhafte Sequenz löst ein klassisches Use-After-Free-Szenario aus . Während der Wiederherstellung kann KVM das verwendete Root-Verzeichnis entfernen und als ungültig markieren. Da der Health-Check jedoch bereits ausgeführt wurde, erstellt das System weiterhin Mappings unter einem nicht mehr gültigen Root-Verzeichnis. Interessanterweise existiert dieses Sortierproblem bereits seit 2008 im Code, wurde aber erst nach der Veröffentlichung von Linux-Kernel 5.9 im Juli 2020 kritisch und ausnutzbar , da eine Direktive eingeführt wurde, deren Durchsetzung das System einfach einstellte.
Anforderungen und Einschränkungen
Damit Zapscape ausgenutzt werden kann, muss die Umgebung sehr spezifische Anforderungen erfüllen. Zunächst muss die verschachtelte Virtualisierung im KVM-Modul aktiviert sein. Diese Konfiguration ermöglicht eine dreistufige Architektur (L0, L1 und L2). Der Angreifer muss den Angriff von der L1-Ebene aus starten , wofür Root-Rechte auf der entsprechenden virtuellen Maschine erforderlich sind. Von dort aus manipuliert der Angreifer die Speichermodi, während die Aktivität des L2-Sub-Gasts den L0-Host dazu zwingt, Quota-Seiten abzurufen, was zu Speicherbeschädigung führt.
Auf Hardwareebene variieren die Bedingungen je nach Hersteller. Bei AMD-Systemen mit verschachtelten Seitentabellen ( SVM ) ist die Schwachstelle einfacher auszunutzen und erfordert keine zusätzlichen Funktionen. Im Gegensatz dazu setzt das Szenario bei Intel-Prozessoren voraus, dass der L1-Gast über EPT-Pagewalk-Funktionen der vierten und fünften Ebene verfügt . Dies beschränkt den Angriffsvektor bei Intel auf neuere Architekturen, insbesondere ab der Ice Lake-SP-Familie.
Es ist erwähnenswert, dass es dem öffentlichen Proof of Concept zwar gelungen ist, in kontrollierten Umgebungen auf den Host zu gelangen, Sicherheitsforscher jedoch berichtet haben, dass der Exploit auf bestimmten neu kompilierten Kerneln lediglich die virtuelle Maschine des Angreifers zum Absturz bringt und somit eher als Denial-of-Service-Angriff denn als vollständiges Entkommen fungiert.
Abschwächungsmaßnahmen, Ausbesserungen und Strategien
Die endgültige Lösung für Zapscape wurde im Juli letzten Jahres in den Linux-Repositories mit einem Patch veröffentlicht, der die Validierungsreihenfolge korrigiert. Dieser Fix verschiebt die Prüfung auf veraltete Root-Verzeichnisse nach der MMU-Seitenzuweisung und stellt so sicher, dass der Hypervisor keine aktiven Mappings unter einem gelöschten Root-Verzeichnis erstellt. Diese Korrekturen wurden bereits in die stabilen Kernel-Zweige implementiert und werden von verschiedenen Distributionen breit gestreut.
Für Administratoren, die nicht sofort ein Upgrade durchführen können, stehen hochwirksame temporäre Maßnahmen zur Verfügung. Die wichtigste Maßnahme ist die Deaktivierung der verschachtelten Virtualisierung auf allen Servern, auf denen sie nicht unbedingt erforderlich ist. Dies geschieht durch Übergabe des Parameters `nested=0` an die Module `kvm_amd` oder `kvm_intel` in den modprobe-Konfigurationsdateien. Diese Maßnahme erfordert das Neuladen des Moduls, wodurch alle aktiven virtuellen Maschinen gestoppt werden müssen.
Sollten Sie mehr erfahren wollen, finden Sie die Details unter folgendem Link.