Im Werkzeug zur Ausf\u00fchrung isolierter Container, runc, das in Docker und Kubernetes verwendet wird, wurde die Schwachstelle CVE-2024-21626 entdeckt, die den Zugriff auf das Dateisystem der Host-Umgebung aus einem isolierten Container erm\u00f6glicht. W\u00e4hrend eines Angriffs kann ein Angreifer bestimmte ausf\u00fchrbare Dateien in der Host-Umgebung \u00fcberschreiben und somit die Ausf\u00fchrung seines Codes au\u00dferhalb des Containers erreichen. In den Runtime-Umgebungen crun und youki, die runc verwenden, sowie in LXC tritt das Problem nicht auf. Die Schwachstelle wurde in der Version runc 1.1.12 behoben. <\/p>\n
Bei der Verwendung von Docker- oder Kubernetes-Tools kann ein Angriff durch die Erstellung eines speziell gestalteten Container-Images erfolgen, nach dessen Installation und Start auf das externe Dateisystem aus dem Container zugegriffen werden kann. Bei der Verwendung von Docker besteht die M\u00f6glichkeit, durch ein speziell gestaltetes Dockerfile Ausbeutung zu betreiben. Die Schwachstelle kann auch ausgenutzt werden, wenn Prozesse im Container mit dem Befehl «runc exec» gestartet werden, indem das Arbeitsverzeichnis an den Namespace der Host-Umgebung gebunden wird. <\/p>\n
Die Schwachstelle wird durch ein Leck interner Dateideskriptoren verursacht. Vor der Ausf\u00fchrung von Code innerhalb des Containers schlie\u00dft runc alle Dateideskriptoren mit dem Flag O_CLOEXEC. Dennoch bleibt nach der anschlie\u00dfenden Ausf\u00fchrung der Funktion setcwd() ein offener Dateideskriptor, der auf das Arbeitsverzeichnis verweist und weiterhin nach dem Start des Containers zug\u00e4nglich bleibt. Es wurden mehrere grundlegende Angriffszenarien auf die Host-Umgebung vorgeschlagen, die den verbleibenden Dateideskriptor nutzen. <\/p>\n
Beispielsweise kann der Angreifer im Container-Image den Parameter process.cwd angeben, der auf «\\\/proc\\\/self\\\/fd\\\/7\\\/» verweist, was zu einer Bindung des Arbeitsverzeichnisses an den Prozess pid1 im Container f\u00fchrt, das sich im Mount-Pfad der Host-Umgebung befindet. So kann im Container-Image der Start von «\\\/proc\\\/self\\\/fd\\\/7\\\/..\\\/..\\\/..\\\/bin\\\/bash» konfiguriert werden und durch die Ausf\u00fchrung eines Shell-Skripts der Inhalt von «\\\/proc\\\/self\\\/exe» \u00fcberschrieben werden, welches auf die Host-Kopie von \\\/bin\\\/bash verweist. <\/p>\n
Eine weitere Angriffsvariante erm\u00f6glicht es einem Angreifer, der innerhalb des Containers eingeschr\u00e4nkt ist, Zugriff auf das Verzeichnis der Host-Umgebung zu erhalten, wenn in dem ausgew\u00e4hlten Container privilegierte Prozesse mithilfe des Befehls «runc exec mit der Option «—cwd» gestartet werden. Der Angreifer kann den Pfad des gestarteten Prozesses durch einen symbolischen Link ersetzen, der auf «\\\/proc\\\/self\\\/fd\\\/7\\\/» verweist, und die \u00d6ffnung von «\\\/proc\\\/$exec_pid\\\/cwd» erreichen, um auf das Dateisystem auf der Host-Seite zuzugreifen. Der Angreifer kann auch die \u00dcberschreibung von ausf\u00fchrbaren Dateien auf der Host-Umgebung erreichen, indem er die Ausf\u00fchrung einer Datei aus der Host-Umgebung («\\\/proc\\\/self\\\/fd\\\/7\\\/..\\\/..\\\/..\\\/bin\\\/bash») organisiert und anschlie\u00dfend die Datei «\\\/proc\\\/$pid\\\/exe» \u00fcberschreibt, die auf die gestartete Datei verweist. <\/p>\n
Dar\u00fcber hinaus wurden in den Komponenten des Docker-Toolkits f\u00fcnf weitere Schwachstellen festgestellt: <\/p>\n