Am Mittwoch wurde PwnEscape veröffentlicht, eine Lücke im Linux-Kernel mit dem Schweregrad 9.3. Sie erlaubt es einer virtuellen Maschine, aus ihrer Isolation auszubrechen und den Wirtsrechner zu erreichen — und damit möglicherweise auch die virtuellen Maschinen anderer Kunden auf derselben Hardware.
Gefunden wurde sie bei einer ausgeschriebenen Sicherheitsprüfung des Anbieters Vercel, der den Befund am 3. Oktober bestätigte.
Der Fehler sitzt nicht dort, wo man ihn vermutet
Das Bemerkenswerte vorweg: Der Fehler steckt nicht im Virtualisierungsprogramm, sondern im Netzwerkcode des Linux-Kernels.
Wenn eine virtuelle Maschine ein Netzwerkpaket abschickt, darf sie mitteilen, an welcher Stelle der Wirtsrechner später eine Prüfsumme einsetzen soll. Das ist eine gewöhnliche Beschleunigungsmassnahme — der Gast spart sich die Rechenarbeit, der Wirt erledigt sie.
Der Kernel prüfte diese Positionsangabe fehlerhaft. Die Prüfsumme landete dadurch an einer falschen Stelle im Speicher und konnte einen Teil des Pakets nachträglich verändern, der zuvor bereits kontrolliert worden war.
Was ein Angreifer damit erreicht — und was nicht
Hier lohnt es sich, genau zu sein, weil die Meldungen dazu auseinandergehen.
Belegt für den laufenden Betrieb: Ein Gast kann Speicher des Wirtsrechners auslesen — etwa 32 Byte je Paket. Zwei präparierte Pakete genügten, um einen Testrechner zum Absturz zu bringen.
Nur im Labor gezeigt: das Ausführen eigener Befehle auf dem Wirt.
Der Unterschied ist erheblich. «Fremder Speicher wird lesbar» ist ernst genug — in diesem Speicher stehen Daten anderer Kunden. Aber es ist nicht dasselbe wie die vollständige Übernahme, und wer beides gleichsetzt, bewertet die Lage falsch.
Die Forscher rechnen damit, dass brauchbare Angriffswerkzeuge innerhalb weniger Wochen verfügbar sind. Angriffe sind bislang nicht gemeldet.
Wir haben nachgesehen, und das Ergebnis ist unbequem
Auf unserem eigenen Server haben wir drei Dinge abgefragt: welcher Kernel läuft, ob die Virtualisierungsmodule geladen sind und ob virtio-Treiber aktiv sind.
Das Ergebnis:
Kernel 5.15.0-191-generic
KVM-Module keine
virtio-Module acht
Keine Virtualisierungsmodule, aber virtio-Treiber: Der Server ist selbst ein Gast. Er läuft als virtuelle Maschine auf der Hardware eines Anbieters.
Damit ist die Lage klar — und für uns wie für die meisten unserer Kunden dieselbe: Der verwundbare Code läuft nicht auf unserem Server, sondern eine Ebene höher. Wir können ihn nicht aktualisieren. Wir sehen nicht einmal, ob es jemand getan hat.
Was das für einen vServer-Kunden bedeutet
Die übliche Handlungsanweisung lautet «Update einspielen». Sie greift hier nicht, und das ist der eigentliche Punkt dieses Beitrags.
Wer einen vServer mietet, ist bei einer solchen Lücke nicht verwundbar, sondern gefährdet — und zwar durch jemand anderen. Nicht die eigene Maschine hat das Problem, sondern die Maschine darunter, auf der auch fremde Kunden liegen.
Dagegen hilft keine Einstellung im eigenen System. Es bleibt genau eine Handlung: beim Anbieter nachfragen.
Und weil diese Frage nur etwas wert ist, wenn man die Antwort einordnen kann, hier die drei Punkte, auf die es ankommt:
Ist der Wirtskernel aktualisiert? Die Korrektur ging am 8. Oktober in den Entwicklungszweig und am 14. in den Hauptzweig; sie wurde auf alle gepflegten Reihen zurückportiert. Ein Anbieter mit gepflegten Systemen hat sie also verfügbar.
Wurde neu gestartet? Das ist die entscheidende Frage. Ein Kernel-Update wirkt erst nach einem Neustart oder mit Live-Patching. Mehrere Anbieter haben am vergangenen Wochenende Neustarts gefahren — das ist ein gutes Zeichen, kein lästiges.
Gibt es überhaupt eine Antwort? Auch das ist eine Auskunft. Wer auf eine sachliche Frage nach einer veröffentlichten Lücke nichts sagt, sagt damit etwas.
Der Befund, der uns selbst betrifft
Beim Nachsehen ist uns noch etwas aufgefallen, und es gehört hierher, weil es zur Sache passt.
Auf unserem Server läuft Kernel 5.15.0-191. Installiert ist bereits 5.15.0-198. Zwischen beiden liegt ein Neustart, der noch aussteht.
Für PwnEscape ändert das nichts — die Lücke sitzt beim Anbieter, nicht bei uns. Es ist aber genau der Zustand, den wir im September schon einmal beschrieben haben: Ein Update ist eingespielt und trotzdem nicht in Betrieb. Das gilt für fremde Systeme so wie für eigene, und man sieht es nur, wenn man nachsieht.
Der Neustart ist eingeplant. Wir schreiben das hier hin, weil es wenig überzeugend wäre, zu Updates zu raten und den eigenen offenen Punkt zu verschweigen.
Was heute zu tun ist
Wenn Sie einen vServer mieten: eine kurze Mail an den Anbieter, mit Verweis auf PwnEscape. Gefragt ist nicht, ob «alles sicher» ist, sondern ob der Wirtskernel aktualisiert und neu gestartet wurde.
Wenn Sie selbst virtualisieren: Kernel aktualisieren und neu starten. Die laufende Fassung zählt, nicht die installierte — warum die Versionsnummer dabei in die Irre führt, haben wir vergangene Woche beschrieben.
Wenn Sie bei uns hosten: Wir stellen dieselbe Frage an unseren Anbieter und geben die Antwort weiter, sobald sie vorliegt.