Vghost: Neun Jahre alte Lücke im Linux-vhost-Subsystem erlaubt Root und VM-Ausbruch

Entdeckt wurde der Fehler vom Tencent Zhuque Lab, das am 3. August einen Fix veröffentlichte und am 12. Oktober eine ausführliche Analyse mit funktionierenden Demonstrationen beider Angriffe nachreichte. Hinweise auf eine Ausnutzung in freier Wildbahn gibt es bislang nicht.

vhost beschleunigt Netzwerk- und andere Ein-/Ausgabe für virtuelle Maschinen und Container. Ein lokaler Nutzer erreicht das Subsystem durch Öffnen eines Gerätenotens, in der Regel /dev/vhost-net oder /dev/vhost-vsock. Auf dem Host erhält ein unprivilegierter Nutzer darüber einen zuverlässigen Weg, beliebige Kerneladressen zu lesen und zu beschreiben, KASLR zu umgehen und zu Root zu eskalieren. Der Angriff ist deterministisch: Er benötigt weder Speicher-Grooming noch günstiges Timing.

Der zweite Angriffsweg ist enger gefasst. Steht das virtio-Gerät einer VM hinter einer virtuellen IOMMU mit aktiviertem iommu_platform und läuft vhost im Device-IOTLB-Modus, kann ein nicht vertrauenswürdiger Gast denselben Fehler auslösen und den Host-Kernel zu einem Schreibzugriff außerhalb der Grenzen in den QEMU-Prozess des Hosts bewegen. Von dort lässt sich ein Funktionszeiger in QEMU überschreiben und der weitere Ablauf des Host-Prozesses steuern — oder dieser zum Absturz bringen.

Technischer Hintergrund

vhost hält einen kleinen Cache der Speicherabbildungen hinter jedem virtuellen Ring und den gemeinsam genutzten Warteschlangen. Ein Cache-Treffer gilt als Beleg dafür, dass die Region bereits geprüft wurde. Geleert wird der Cache beim Aktualisieren oder Invalidieren der Abbildung sowie beim Zurücksetzen der Warteschlange — nicht jedoch, wenn die Kommandos VHOST_SET_VRING_ADDR oder VHOST_SET_VRING_NUM Adressen oder Größe des Rings im laufenden Betrieb ändern.

Mit angehängtem Device-IOTLB akzeptieren diese Kommandos die neuen Adressen ungeprüft und verschieben die Prüfung auf einen späteren Schritt. Ist der Cache einmal gefüllt, läuft die nachgelagerte Prüfung nie, und vhost übersetzt neue Adressen weiterhin über die alte Abbildung. Der Kernel kopiert dann ohne Grenzprüfung Daten zu oder von diesem Zeiger, sodass ein Schreibzugriff auf den Used Ring oder das Lesen eines Deskriptors außerhalb der abgebildeten Region landet.

Rund neun Jahre blieb der Fehler unentdeckt, weil erst zwei für sich genommen plausible Änderungen ihn erzeugten: Eine Änderung von 2017 (Linux 4.11) führte den Cache und seine Abkürzung ein, eine Änderung von 2020 (Linux 5.9) verlagerte die Adressprüfung aus dem Kommando in einen späteren Schritt und entfernte damit die Kontrolle, die die veraltete Übersetzung aufgedeckt hätte.

Betroffene Systeme und Gegenmaßnahmen

Betroffen sind Linux-Kernel von 4.11 bis 7.2-rc4. Tencent reproduzierte die vollständige Kette vom lokalen Nutzer zu Root auf fünf Distributionskerneln: Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0 und Oracle Linux 10.2. Unter Ubuntu war der Gerätenote auf die Gruppe kvm beschränkt, Ausgangspunkt war dort also eine Mitgliedschaft in dieser Gruppe; auf den vier anderen getesteten Images war der Knoten mit Modus 0666 für alle lesbar, sodass jeder lokale Nutzer ihn erreichen konnte.

Der Fix (Commit de845981da67) leert den Cache bei jeder Neukonfiguration des Rings. Nötig ist die Installation eines Kernels, der ihn enthält, samt Neustart; Hersteller können den Fix auch ohne Versionsänderung zurückportieren. Red Hat, Amazon Linux und Oracle Linux haben Korrekturen ausgeliefert. Ubuntu hat 22.04 behoben und führte die Kernel für 24.04 und 26.04 mit Stand 13. Oktober weiterhin als in Arbeit.

Bis ein korrigierter Kernel eingespielt ist, empfiehlt sich, den Zugriff auf die vhost-Gerätenoten einzuschränken:

• Weltweiten Zugriff auf /dev/vhost-net und /dev/vhost-vsock entfernen
• Die besitzende Gruppe auf vertrauenswürdige Virtualisierungsdienste begrenzen
• Mitgliedschaft in dieser Gruppe bei verwundbarem Kernel als Privileg behandeln

Für den Ausbruch vom Gast zum Host gibt es keinen Zwischenbehelf; hier hilft nur der gepatchte Kernel.

Bewertung

Die Lücke gilt als hoch, nicht als kritisch, wobei die Bewertungen auseinandergehen. Das CVE-Team von kernel.org vergibt 8,8 und stuft den Scope als geändert ein, da der Schreibzugriff vom Gast aus Speicher im QEMU-Prozess des Hosts erreicht und damit die Grenze zwischen Gast und Host überschreitet. Red Hat vergibt 7,3 bei unverändertem Scope und sieht die Auswirkung innerhalb der Vertrauensgrenze des Hosts; auch die Integritätsauswirkung bewertet Red Hat niedriger. Amazon kommt auf 7,8, Oracle auf 7,3.

Gefunden wurde der Fehler mit Unterstützung von Corvus AI, einem von Tencent gebauten Multi-Agenten-System für die Kernel-Schwachstellenforschung. Der Upstream-Fix würdigt es mit einer “Assisted-by”-Zeile, und nach Angaben von Tencent hat die Pipeline die Lücke aufgespürt. Es handelt sich um maschinell unterstützte Forschung, nicht um einen von KI ausgeführten Angriff. Dasselbe Team und dieselbe Pipeline standen hinter einer im August offengelegten, 18 Jahre alten SCTP-Kernel-Lücke, die ebenfalls Root-Rechte erreichte und im Test aus einem Container ausbrach.