Im Werkzeug zur Verwaltung isolierter Linux-Container in Docker Schwachstelle (), die unter bestimmten Umständen den Zugriff auf die Host-Umgebung aus dem Container ermöglicht, wenn die Möglichkeit besteht, eigene Images im System auszuführen oder wenn Zugriff auf den ausgeführten Container besteht. Das Problem tritt in allen Docker-Versionen auf und bleibt ungepatcht (vorgeschlagen, aber bisher nicht angenommen, , das die Aussetzung der Arbeit des Containers während der Ausführung von Operationen mit dem Dateisystem implementiert).
Die Schwachstelle ermöglicht das Extrahieren von Dateien aus dem Container an beliebige Stellen im Dateisystem des Host-Systems, wenn der Befehl „docker cp“ ausgeführt wird. Das Extrahieren von Dateien erfolgt mit Root-Rechten, was es ermöglicht, alle Dateien in der Host-Umgebung zu lesen oder zu schreiben, genug, um die Kontrolle über das Host-System zu erlangen (zum Beispiel kann /etc/shadow überschrieben werden).
Der Angriff kann nur zu dem Zeitpunkt durchgeführt werden, an dem der Administrator den Befehl „docker cp“ zum Kopieren von Dateien in den Container oder aus diesem heraus ausführt. Daher muss der Angreifer irgendwie den Docker-Administrator davon überzeugen, dass diese Operation notwendig ist, und den Pfad, der beim Kopieren verwendet wird, vorhersagen. Andererseits kann der Angriff beispielsweise durch die Bereitstellung von Cloud-Diensten erfolgen, die Mittel zum Kopieren von Konfigurationsdateien in den Container bereitstellen, die mit dem Befehl „docker cp“ erstellt wurden.
Das Problem wird durch einen Mangel in der Anwendung der Funktion , die den absoluten Pfad im Haupt-Dateisystem basierend auf dem relativen Pfad berechnet, der die Platzierung des Containers berücksichtigt. Während der Ausführung des Befehls „docker cp“ tritt kurzzeitig ein , bei dem der Pfad bereits überprüft wurde, aber die Operation noch nicht ausgeführt wurde. Da das Kopieren im Kontext des Haupt-Dateisystems des Host-Systems erfolgt, kann innerhalb eines bestimmten Zeitrahmens der Verweis auf einen anderen Pfad ersetzt werden, sodass das Kopieren von Daten an beliebige Stellen im Dateisystem außerhalb des Containers initiiert wird.
Da das Zeitfenster für das Auftreten der Race Condition stark begrenzt ist, in einem vorbereiteten Bei der Durchführung von Kopieroperationen aus einem Container gelang es, in weniger als 1 % der Fälle einen erfolgreichen Angriff durch zyklisches Ersetzen des symbolischen Links im Pfad, der für die Kopieroperation verwendet wurde, durchzuführen (ein erfolgreicher Angriff wurde nach etwa 10 Sekunden kontinuierlicher Versuche in einer Schleife, eine Datei mit dem Befehl „docker cp“ zu kopieren, durchgeführt).
Bei der Durchführung einer Kopieroperation in den Container kann ein wiederholbarer Angriff auf die Überschreibung einer Datei im Hosts-System in nur wenigen Iterationen erreicht werden. Diese Angriffsmöglichkeit ist darauf zurückzuführen, dass bei der Kopierung in den Container das Konzept „chrootarchive“ angewendet wird, wonach der Prozess archive.go das Archiv nicht im chroot-Wurzelverzeichnis des Containers, sondern im chroot-Elternverzeichnis des Zielpfades, der von dem Angreifer kontrolliert wird, entpackt und dabei die Ausführung des Containers nicht stoppt (chroot wird als Hinweis für die Ausnutzung eines Rennzustands verwendet).
Quelle: opennet.ru
