Firecracker-MicroVM-Flucht durch Manipulation von KVM-Registern

Sicherheitsforscher haben eine kritische Schwachstelle in Firecracker demonstriert, der Open-Source-Virtualisierungstechnologie, die für den Betrieb serverloser Computing-Plattformen genutzt wird. Durch die Manipulation gespeicherter CPU-Register während eines bestimmten Kernel-Übergangs erreichten sie Codeausführung als Root auf dem Host-Rechner. Der im November 2026 detailliert beschriebene Exploit ermöglicht es einem Angreifer innerhalb einer Gast-Virtual-Machine, die Kontrolle über den Host-Prozess zu übernehmen, der diese VM verwaltet, ohne diesen zum Absturz zu bringen oder Standard-Monitoring-Tools zu alarmieren.

Was passiert ist

Das Forschungsteam, das unter dem Namen PWN.AI Security Research veröffentlichte, stellte den zweiten Teil ihrer „PwnEscape“-Serie vor. Diese Arbeit baut auf einem zuvor offengelegten Speicher-Primitive auf, das es einem Gast erlaubte, ausgewählten physischen Host-Speicher zu lesen und zu schreiben. In diesem Folgeartikel verknüpften sie dieses Primitive mit einer Technik, um den Live-Ausführungszustand des Firecracker-Prozesses auf dem Host zu lokalisieren und zu modifizieren. Das Ziel war Firecracker Version 1.16.1, das auf einem x86-64-System mit Linux-Kernel 7.0.0-1011-aws lief.

Der Exploit verlässt sich nicht auf traditionelle Buffer Overflows oder Softwarefehler in der Anwendungslogik. Stattdessen missbraucht er den Mechanismus, durch den der Linux-Kernel den Prozessorzustand beim Wechsel zwischen der Gast-VM und dem Host-Userspace-Prozess speichert und wiederherstellt. Indem die Angreifer den genauen Speicherort identifizierten, an dem die Register des Host-Threads während eines KVM-Exits gespeichert werden, leiteten sie den Ausführungsfluss um. Sie zwangen den Host-Prozess, einen write-Systemaufruf auszuführen, der eine spezifische Marker-Zeichenkette im Standard-Fehlerstrom (stderr) ausgab. Entscheidend ist, dass der Exploit nach der Ausführung dieser Payload die ursprünglichen Registerwerte wiederherstellte, sodass der Firecracker-Prozess normal weiterlaufen konnte. Die VM blieb über SSH erreichbar, und vom Host-Kernel wurden keine Fehler protokolliert.

Wie es funktioniert

Der Kern des Angriffs basiert auf dem Verständnis dafür, wie virtuelle CPUs (vCPUs) mit dem Host interagieren. Jede vCPU in einer Firecracker-MicroVM entspricht einem Thread im Host-Prozess. Wenn der Gast eine Operation ausführen muss, die eine Intervention des Hosts erfordert – etwa die Behandlung eines Interrupts oder der Zugriff auf emulierte Hardware –, verlässt der Thread das KVM-Kernelmodul und kehrt in den Userspace zurück. Während dieses Exits speichert der Kernel den aktuellen Zustand des Threads – einschließlich Instruction Pointer und Stack Pointer – in einer Struktur namens pt_regs.

Die Angreifer nutzten ihr bestehendes Speicherzugriffs-Primitive, um den physischen Host-Speicher nach diesen gespeicherten Registerstrukturen zu durchsuchen. Zuerst platzierten sie ein eindeutiges Byte-Muster, einen sogenannten Nonce, in einer bekannten Guest-Seite. Durch das Durchlaufen der Extended Page Tables (EPT) übersetzten sie die guest-physische Adresse in eine host-physische Adresse. Anschließend mappen sie die Host-Seitentabellen rückwärts, um herauszufinden, welcher Host-Prozess diese physische Seite gemappt hatte, was effektiv die Identifizierung des Firecracker-Prozesses und seines Speicherslayouts trotz Address Space Layout Randomization (ASLR) ermöglichte.

Nachdem der Prozess identifiziert war, suchten sie nach einem pt_regs-Frame, der dem erwarteten Zustand eines Threads entsprach, der von einem KVM_RUN-Ioctl-Aufruf zurückkehrte. Sie validierten Kandidaten, indem sie den gespeicherten Instruction Pointer gegen bekannte Firecracker-Codeadressen prüften und sicherstellten, dass die Systemaufrufargumente einer aktiven KVM-Anfrage entsprachen. Nach der Lokalisierung des korrekten Frames modifizierten sie den gespeicherten Instruction Pointer so, dass er auf einen write-Wrapper in der Firecracker-Binärdatei zeigte, und passten den Stack Pointer an, um ihre Payload-Argumente einzuschließen. Als der Gast einen KVM-Exit durch Schreiben auf die serielle Schnittstelle auslöste, setzte der Host-Thread am angreiferkontrollierten Adresse fort, führte den Schreibvorgang aus und kehrte dann über eine sorgfältig konstruierte Rückkehrsequenz zu seinem ursprünglichen Pfad zurück.

Wichtige Details

• Zielumgebung: Firecracker v1.16.1 auf x86-64, Host-Kernel 7.0.0-1011-aws, Gast-Kernel 6.18.44+.
• Berechtigungsstufe: Der Exploit erreichte Codeausführung als Root, da die Testinstanz direkt als Root ohne Jailer oder Namespace-Einschränkungen gestartet wurde.
• Tarnung: Die VM blieb nach dem Exploit voll funktionsfähig; SSH-Verbindungen bestanden weiter, und die Uptime-Zähler liefen normal weiter.
• Speicher-Primitive: Der Angriff erfordert die vorherige Fähigkeit, bestimmte physische Host-Speicherseiten aus dem Inneren des Gastes zu lesen und zu schreiben.
• Validierung: Die Forscher bestätigten den Erfolg, indem sie die Marker-Zeichenkette N8V23M2\n aus dem stderr des Host-Prozesses erfassten, während sie gleichzeitig überprüften, dass ausführbarer Text und Shared Libraries unverändert blieben.
• Wiederherstellung: Der Exploit stellt explizit drei modifizierte Stack-Wörter nach der Ausführung wieder her, wodurch keine unmittelbaren forensischen Spuren im temporären Stack-Bereich hinterlassen werden.

Warum das wichtig ist

Für Ingenieure, die serverlose Plattformen oder isolierte Container-Umgebungen entwickeln, verdeutlicht diese Demonstration die Risiken, die entstehen, wenn man sich ausschließlich auf Hypervisor-Grenzen für die Sicherheit verlässt. Firecracker ist für hochdichte Isolation konzipiert, aber dieser Exploit zeigt, dass ein Gast, der die Speicherisolationsgrenze durchbricht, den Verwaltungsthread selbst kapern kann. Dies ist besonders gefährlich, weil der Angriff den Dienst nicht zum Absturz bringt, was ihn schwer über Standard-Verfügbarkeitsmonitore erkennbar macht.

Die Auswirkung hängt stark von der Konfiguration der Bereitstellung ab. Die Forscher wiesen darauf hin, dass ihr Testsetup Firecracker als Root ohne zusätzliche Eindämmungsschichten wie seccomp-Filter oder User Namespaces ausführte. In Produktionsumgebungen schränken diese Kontrollen ein, was ein Angreifer tun kann, selbst wenn er Codeausführung erreicht. Allerdings bleibt die Fähigkeit, den Ausführungsfluss innerhalb des VMM-Prozesses umzuleiten, eine schwere Bedrohung, die es Angreifern potenziell ermöglicht, seccomp-Richtlinien zu umgehen, wenn sie Systemaufrufargumente manipulieren oder zu Gadget-Ketten innerhalb des erlaubten Speicherbereichs springen können.

Was Sie tun können

• Privilegienstufen prüfen: Stellen Sie sicher, dass Firecracker-Prozesse nicht als Root laufen. Nutzen Sie den integrierten Jailer, um Privilegien sofort beim Start abzusenken und den Dateisystemzugriff einzuschränken.
• Seccomp-Filter aktivieren: Konfigurieren Sie strenge seccomp-Profile, um die für den Firecracker-Prozess verfügbaren Systemaufrufe zu begrenzen und damit die Angriffsfläche für mögliche Codeausführungen zu reduzieren.
• User Namespaces nutzen: Führen Sie Firecracker innerhalb von User Namespaces aus, um den Prozess vom Root-Benutzer des Hosts zu isolieren und die Auswirkungen einer Flucht zu begrenzen.
• Anomales Verhalten überwachen: Implementieren Sie Logging für unerwartete stderr-Ausgaben oder ungewöhnliche Muster bei Systemaufrufen von VMM-Prozessen, obwohl dieser Exploit darauf ausgelegt ist, unbemerkt zu bleiben.
• Aktuell bleiben: Verfolgen Sie Updates des Firecracker-Projekts und wenden Sie Patches im Zusammenhang mit Speicherisolierung und KVM-Interaktionsbehandlung an, sobald sie verfügbar sind.
• Speicher-Primitives überprüfen: Untersuchen Sie, wie Ihre Workload möglicherweise physische Host-Speicher-Mappings für Gäste offenlegt, und härten Sie diese Schnittstellen gegen unbefugte Übersetzungs-Lookups ab.