Cyberbedrohungen
Neue Techniken zum Ausbruch aus der Docker Desktop-VM
TrendAI™ Research hat mehrere neue Methoden entdeckt, mit denen Angreifer die WSL2-VM (Windows Subsystem for Linux 2) von Docker Desktop umgehen und beliebigen Code auf dem Host ausführen können. Unsere Analyse zeigt die Risiken.
Save to Folio
Wichtige Erkenntnisse
- TrendAI™ Research hat mehrere neue Techniken aufgedeckt, mit denen Angreifer die Isolierung der WSL2-VM von Docker Desktop umgehen und Code auf dem Windows-Host ausführen können.
- Diese VM-Escape-Pfade nutzen legitime Docker-Desktop-Mechanismen aus. So können harmlose, benutzerorientierte Funktionen für die Codeausführung auf Host-Ebene zweckentfremdet werden.
- Unternehmen sollten die Überwachung und Governance rund um Entwicklerumgebungen verstärken, Docker-Desktop-Konfigurationen validieren und auf anomale API-Nutzung oder unerwartete Binärausführung achten, um die Risiken zu mindern.
Heutzutage wird Sicherheit durch die Implementierung mehrerer Ebenen von Abwehrmaßnahmen, Isolation und Schutzmechanismen gewährleistet. Sind Isolationstechniken vorhanden, so werden die Sicherheitsrisikobewertungen aufgrund des impliziten Vertrauens in die Isolation selbst herabgestuft. Was aber, wenn die Isolation selbst durchbrochen wurde?
Wir haben fünf neue Möglichkeiten zur Umgehung der Isolation zwischen der virtuellen Maschine (VM) von Docker Desktop und dem Windows-Host unter Verwendung des Windows-Subsystems für Linux (WSL) entdeckt. Die folgende Darstellung stellt eine Zusammenfassung der Analyse dar. Alle technischen Einzelheiten liefert der Originalbeitrag.
WSL2 (Windows Subsystem for Linux 2) ist eine performante Virtualisierungstechnik, die einen echten Linux-Kernel in einer schlanken, verwalteten VM unter Windows 10/11 ausführt. Es bietet volle Systemcall-Kompatibilität, hohe I/O-Performance, GPU-Zugriff und nahtlose Integration in Windows.
Docker Desktop soll in Unternehmensumgebungen Teams dabei unterstützen, Software schneller zu entwickeln, zu testen und für die Implementierung vorbereiten. Docker Desktop stand auch beim Pwn2Own in Berlin 2025 auf dem Prüfstand, und die Herausforderung nicht nur darin, mit Standardberechtigungen aus dem Docker-Container auszubrechen, sondern auch, daraufhin Code auf dem zugrunde liegenden Host auszuführen.
Achtung: Es gibt einen Unterschied zwischen Container Escapes der Docker Engine und solchen der Docker Desktop VM. Erstere werden in der Regel durch Ausnutzung einer Schwachstelle im Linux-Kernel oder anderer Schwachstellen in Docker Desktop mithilfe eines bösartigen Containers erreicht. Unter WSL verschaffen solche Container-Escapes dem Angreifer jedoch nur die Kontrolle über die Docker-Desktop-VM, da die Docker Engine innerhalb einer WSL-VM läuft.
Die Docker Desktop VM ist eine Linux-Distribution, die von WSL als Gastbetriebssystem instanziiert wird und auf einer speziellen Version von Hyper-V als isolierte VM läuft. Der Angreifer muss Wege finden, aus dieser Docker Desktop VM auf den Host auszubrechen, um die Codeausführung im Host-Betriebssystem unter dem aktuellen Benutzer zu erreichen.
Zur Klarstellung: Um einen Docker VM-Escape zu erreichen, ist entweder ein Docker-Engine Container-Escape oder Zugriff auf den Docker-Daemon erforderlich. Die in unserer Analyse erwähnten Techniken würden nur bei einem über TCP exponierten Docker-Daemon auf Windows-Hosts mit WSL2-Backend funktionieren. Zudem basieren die Techniken nicht auf dem Docker Socket. Wir konzentrieren uns nicht auf Container-Escapes, um den Missbrauch des VM-Escapes zu schildern. Diese Untersuchung basierte auf Docker Desktop für Windows in der Version 4.42, das unter WSL2 ausgeführt wurde. Alle Fälle wurden dem Docker-Sicherheitsteam gemeldet.
Architektur von Docker Desktop unter WSL
Bild 1. Docker Desktop-Architektur unter WSL
Bei der Verwendung von WSL führt Docker Desktop für Windows die Container innerhalb einer WSL-VM aus. Die Container sind vom Windows-Hostbetriebssystem „doppelt isoliert“. Docker-Container befinden sich in der inneren „Isolationsschicht“ der Container Engine. Ein bösartiger Container kann mithilfe eines Kernel-Exploits oder anderer Schwachstellen in die Docker-WSL-VM ausbrechen. Dort verfügt der Angreifer über eine Reihe von Berechtigungen gegenüber dem Host. Keine dieser Berechtigungen erlaubt jedoch die direkte Codeausführung.
Unter bestimmten Umständen gelingt die Code-Ausführung, wenn der Angreifer Startdateien schreibt und darauf wartet, dass der Benutzer den Rechner neu startet. Selbst unter diesen Bedingungen ist es nicht möglich, Code auf dem Host auszuführen, selbst wenn der Angreifer die Docker-WSL-VM kontrolliert. Dazu müsste der Angreifer neue Exploits finden oder andere Techniken anwenden. Dies war der Fall bei einem früheren Pwn2Own-Wettbewerb, bei dem mindestens zwei Techniken zum Ausbrechen aus der Docker-VM verwendet wurden.
Kommunikation zwischen Docker Desktop-Host und VM
Docker Desktop für Windows hat eine modulare und API-orientierte Architektur mit komplexen Interaktionen und mehreren Endpunkten, die unterschiedliche Rollen übernehmen. So gibt es beispielsweise verschiedene APIs für zentrale Verwaltungsaufgaben wie die Verwaltung von Containern, Modulen und Erweiterungen.
Bild 2. Übersicht über die Architektur von Docker Desktop für Windows
Die Docker-Engine empfängt Befehle über die API. Diese Sockets stellen aber auch Funktionen bereit, die von innerhalb der Docker-WSL-VM aufgerufen werden können und Aktionen zurück an die auf dem Host installierten Docker-Desktop-Komponenten ausführen. Alle Komponenten der Standardinstallation werden als aktueller Benutzer ausgeführt, außer in einigen speziellen Konfigurationen. Bei der Überprüfung der Architektur wurden mehr als 40 Sockets identifiziert, die mit Docker-Funktionen in Verbindung stehen. „backend.sock“ und „module-manager.sock“ stellen offenbar bevorzugte Angriffsziele dar. Der Zugriff auf das Host-Dateisystem ist durch die Berechtigungen des aktuellen Benutzers eingeschränkt.
Bild 3. Perspektive des Angreifers aus dem Inneren der VM
Der Angreifer kann zwar keinen Code direkt auf dem Host ausführen, der Host selbst ist dennoch erheblichen Risiken ausgesetzt. Der Angreifer kann ausführbare Dateien überall dort ablegen, wo er über Schreibrechte verfügt, kann diese jedoch nicht ausführen.
Exponierte APIs der Docker Desktop WSL-VM
Docker Desktop stellt fast alle APIs der Komponenten über Linux-Sockets innerhalb der Docker-WSL-VM bereit. Diese APIs sind nicht dokumentiert, weisen jedoch einige Ähnlichkeiten mit der Docker-Engine-API) auf. Sie lassen sich zwar anhand der Docker-Binärdateien rekonstruieren, doch in vielen Fällen reicht die Verwendung der Sockets aus, um die Funktionalität zu ermitteln.
Docker Desktop VM-Escapes
Diese Angriffe gehen davon aus, dass die inneren Container bereits über eine Kernel-Sicherheitslücke oder eine Schwachstelle in der Docker-Architektur ausgebrochen sind. Es gibt jedoch eine Möglichkeit, diesen Escape zu simulieren und Zugriff auf das Dateisystem der Docker-VM zu erhalten.
Docker Desktop in Windows VM Escape über credentialHelper
Diese Methode nutzt eine Kombination aus Manipulation der Einstellungen und freigegebenen Linux-Sockets aus dem Inneren der VM. Docker verfügt über Module zur sicheren Speicherung von Anmeldedaten und unterhält einen eigenen Anmeldedaten-Manager. Der Standardpfad dafür ist ein geschützter Speicherort, sofern der aktuelle Benutzer keine Administratorrechte besitzt. Diese Einstellung kann jedoch auf einen beliebigen Speicherort geändert werden:
Da dieser Pfad vollständig vom Benutzer kontrolliert wird, kann selbst ein Angreifer mit geringen Berechtigungen in drei Schritten Code ausführen und aus der VM entkommen. Wie bereits erwähnt, bietet die öffentlich zugängliche Backend-API zahlreiche Endpunkte, über die Benutzer Docker Desktop von innerhalb der VM steuern können. Alle diese Endpunkte haben Auswirkungen auf den Host, wenn sie von innerhalb der VM aufgerufen werden. Sie zwingen den Docker-Backend-Dienst zum Neustart und zum Neuladen der Konfigurationen und setzen im letzten Fall alle Einstellungen zurück.
Wir haben eine Docker-API entdeckt, die den Nebeneffekt hat, dass die Docker-Backend-Dienste auf dem „Host“ dazu gezwungen werden, den Standard-Credential-Helper aufzurufen, was zu einem Ausbruch aus der Docker VM führte. Sobald der Angreifer die Docker Desktop VM von innen heraus kontrolliert, wird die Ausführung von Code ohne Benutzereingriff möglich, indem die Docker-Desktop-Einstellungen manipuliert und andere Backend-API-Endpunkte missbraucht werden.
Ausbruch über Docker-CLI-Plugins
Docker verfügt über eine durch Plugins erweiterbare Architektur. Die Docker-Befehlszeilenschnittstelle (CLI) unter Windows enthält eine Reihe vordefinierter Plugins. Je nach dem an die Docker-CLI übergebenen Befehl wird dieser von unterschiedlichen Plugins verarbeitet. Standardmäßig liefert Docker eine Reihe von Plugins aus. Alle diese Plugins sind ordnungsgemäß in einem Verzeichnis installiert, für das der aktuelle Benutzer keine Änderungsberechtigung besitzt. Daher ist eine Änderung dieser Plugins im Rahmen eines potenziellen Ausbruchs aus der Docker-VM nicht möglich.
Für diese Methode nutzten wir für die Ausführung von Befehlen bestimmte Komponenten von Docker Desktop, die zur Ausführung von Befehlen auf dem zugrunde liegenden Host führen. Bei unserer Analyse stellten wir fest, dass Docker Desktop einen weiteren Standardpfad zum Laden von Plugins hat. Dieses Verzeichnis wird vom aktuellen Benutzer verwaltet und birgt das Risiko eines Ausbruchs aus der Docker-VM.
VM-Escape mithilfe des Ladens von Docker-CLI-Plugins: app/reset
Ein VM-Escape mithilfe von Docker-CLI-Plugins kann erreicht werden, indem der Pfad C:\Users\[Benutzername]\.docker\cli-plugins erstellt und die Binärdateien in ein bestimmtes Verzeichnis kopiert werden. Ein einfacher Aufruf des Endpunkts „/app/reset“ im Backend-Unix-Socket reicht aus, um die Ausführung dieser neuen Binärdateien auszulösen.
Es ist anzumerken, dass der Plugin-Mechanismus sehr flexibel ist und eine wichtige Komponente von Docker Desktop darstellt. Aus diesem Grund ist davon auszugehen, dass sich durch den Missbrauch anderer Backend-APIs über /app/reset hinaus ein Ausbruch aus der VM erzielen lässt.
VM-Escape mithilfe des Ladens von Docker-CLI-Plugins: module/apply-updates
Ein weiteres exponiertes Linux-Socket ist der Modules-Manager (modules-manager.sock).
Unkontrolliertes Suchpfadelement im Systemeditor von Docker Desktop für Windows
Ein anderer Backend-API-Endpunkt namens „Editor“ hat auf der Host-Seite einen Nebeneffekt. Docker Desktop definiert „Editor“ als jeden Texteditor, der nach der Installation von Docker als solcher erkannt wird, wie beispielsweise VSCode und Notepad. Wenn der aktuelle Benutzer den Pfad zum Editor kontrollieren kann, ist ein Ausbruch aus der VM möglich. Leider lassen diese API-Endpunkte keine Steuerung und Konfiguration des Pfads zur ausführbaren Datei des Editors zu.
Fazit und Empfehlungen
Auch wenn Docker Desktop für Windows unter WSL eine weitere Isolationsebene zwischen Containern und dem Host schafft und nach einem Container-Escape keine direkte Codeausführung zulässt, ist die Architektur von Docker Desktop nicht darauf ausgelegt, einen VM-Escape zu verhindern.
Die internen APIs und Konfigurationsmechanismen von Docker Desktop sind auf Orchestrierung und Benutzerfreundlichkeit ausgelegt und nicht als robuste Sicherheitsgrenzen konzipiert. Sicherheitsteams sollten die Transparenz und Governance auf Entwicklerumgebungen ausweiten und die Verhaltensüberwachung sowie die Konfigurationskontrolle verstärken, um den Missbrauch legitimer Docker-Workflows aufzudecken, anstatt sich ausschließlich auf die Blockierung der direkten Codeausführung zu verlassen.
Anhang
Diese Probleme wurden Docker verantwortungsbewusst gemeldet. Der Anbieter hat alle gemeldeten Fälle geprüft und bestätigt, dass die beschriebenen Verhaltensweisen reproduzierbar sind. Das Unternehmen kam jedoch zu dem Schluss, dass diese Szenarien außerhalb seines definierten Sicherheitsbedrohungsmodells liegen.
Laut Docker setzt der vorbereitende Schritt, das gesamte Dateisystem von Docker Desktop in einen laufenden Container einzubinden, bereits voraus, dass der Angreifer über privilegierten Zugriff auf Systemebene auf dem Host verfügt. Bei diesem Zugriffsniveau wäre ein Angreifer von Natur aus in der Lage, sensible Daten auszulesen, Authentifizierungs-Token zu exfiltrieren oder kritische Systemkomponenten zu manipulieren, ohne auf einen Docker-spezifischen Mechanismus angewiesen zu sein. Da die Angriffsfläche erst nach einer solchen Kompromittierung erreichbar wird, seien die daraus resultierenden VM-Escape-Verhaltensweisen keine eigenständigen Schwachstellen darstellen, die behoben werden müssen.
Docker betont, dass die Garantien von Docker Desktop von einem unbeeinträchtigten Host ausgehen und sich nicht auf Szenarien erstrecken, in denen ein Angreifer bereits erweiterte Zugriffsrechte erlangt hat. Obwohl nicht geplant ist, Korrekturen für diese Fälle herauszugeben, würdigte das Unternehmen die Forschungsarbeit und ermutigte zu weiteren Einreichungen. Dabei wies es darauf hin, dass Erkenntnisse dieser Art dennoch dazu beitragen können, das Verständnis des Ökosystems darüber zu vertiefen, wie harmlose Orchestrierungsmechanismen missbraucht werden können, sobald die Integrität des Hosts verloren gegangen ist.