{"id":113376,"date":"2024-02-03T13:41:10","date_gmt":"2024-02-03T11:41:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes"},"modified":"2024-02-03T13:41:10","modified_gmt":"2024-02-03T11:41:10","slug":"uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes","title":{"rendered":"Sicherheitsl\u00fccke in runc erm\u00f6glicht Ausbr\u00fcche aus Docker- und Kubernetes-Containern","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im Werkzeug zum Starten isolierter Container runc, das in Docker und Kubernetes verwendet wird, wurde die Schwachstelle CVE-2024-21626 gefunden. Diese erm\u00f6glicht den Zugriff auf das Dateisystem der Host-Umgebung aus einem isolierten Container. Bei einem Angriff kann ein Angreifer bestimmte ausf\u00fchrbare Dateien in der Host-Umgebung \u00fcberschreiben und so die Ausf\u00fchrung seines Codes au\u00dferhalb des Containers erreichen. In den Laufzeitumgebungen 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
Im Falle der Verwendung von Docker- oder Kubernetes-Tools kann ein Angriff durch die Vorbereitung eines speziell gestalteten Container-Images erfolgen, nach dessen Installation und Ausf\u00fchrung der Zugriff auf das externe Dateisystem vom Container aus m\u00f6glich ist. Bei der Verwendung von Docker besteht die M\u00f6glichkeit der Ausnutzung \u00fcber ein speziell gestaltetes Dockerfile. Die Schwachstelle kann auch ausgenutzt werden, wenn Prozesse innerhalb des Containers mit dem Befehl «runc exec» ausgef\u00fchrt werden, indem das Arbeitsverzeichnis an den Namespace der Host-Umgebung gebunden wird. <\/p>\n
Die Schwachstelle entsteht durch das Leck interner Dateideskriptoren. Vor der Ausf\u00fchrung von Code innerhalb des Containers schlie\u00dft runc alle Dateideskriptoren mittels des O_CLOEXEC-Flags. Dennoch bleibt nach dem anschlie\u00dfenden Aufruf der Funktion setcwd() ein Dateideskriptor ge\u00f6ffnet, der auf das Arbeitsverzeichnis zeigt und nach dem Start des Containers weiterhin zug\u00e4nglich ist. Es wurden mehrere grundlegende Angriffszenarien auf die Host-Umgebung unter Verwendung des verbleibenden Dateideskriptors vorgeschlagen. <\/p>\n
Zum Beispiel kann der Angreifer im Container-Image den Parameter process.cwd angeben, der auf «\/proc\/self\/fd\/7\/» verweist, was dazu f\u00fchren wird, dass das Arbeitsverzeichnis des Prozesses pid1 im Container, der sich im Mount-Punkt der Host-Umgebung befindet, damit verbunden wird. Damit kann im Container-Image die Ausf\u00fchrung von «\/proc\/self\/fd\/7\/..\/..\/..\/bin\/bash» konfiguriert werden, und durch die Ausf\u00fchrung eines Shell-Skripts kann der Inhalt von «\/proc\/self\/exe» \u00fcberschrieben werden, das auf die Host-Kopie von \/bin\/bash verweist. <\/p>\n
Eine andere Angriffsvariante erm\u00f6glicht es einem Angreifer, der im Container eingeschr\u00e4nkt ist, Zugang zum Verzeichnis der Host-Umgebung zu erhalten, wenn im angegebenen Container privilegierte Prozesse mit dem Befehl «runc exec mit der Option «--cwd» gestartet werden. Der Angreifer kann den Startpfad des ausgef\u00fchrten Prozesses auf ein Symbolisches Link \u00e4ndern, das auf «\/proc\/self\/fd\/7\/» verweist, um Zugang zum Dateisystem der Host-Seite zu erhalten. Der Angreifer kann auch erreichen, dass ausf\u00fchrbare Dateien auf der Host-Umgebung durch die Organisation des Starts einer ausf\u00fchrbaren Datei aus der Host-Umgebung («\/proc\/self\/fd\/7\/..\/..\/..\/bin\/bash») \u00fcberschrieben werden, was die \u00dcberschreibung der Datei «\/proc\/$pid\/exe» zur Folge hat, die auf die gestartete Datei verweist. <\/p>\n
Dar\u00fcber hinaus wurden in den Komponenten des Docker-Toolkits f\u00fcnf weitere Schwachstellen identifiziert: <\/p>\n
\n
CVE-2024-23651 — ein Race-Condition im BuildKit-Paket, das in Docker verwendet wird, um Quellcode in Build-Artefakte zu transformieren. Die Schwachstelle wird durch die Verwendung eines gemeinsamen Mount-Punktes mit Cache («--mount=type=cache,source=») in parallel ausgef\u00fchrten Build-Phasen verursacht, was es erm\u00f6glicht, bei der Verarbeitung eines speziell gestalteten Dockerfiles Zugriff auf Dateien in der Host-Umgebung zu erlangen. Die Schwachstelle wurde in BuildKit 0.12.5 behoben.\n
CVE-2024-23652 — ein Fehler beim L\u00f6schen leerer Dateien, die f\u00fcr den Mount-Punkt bei der Verwendung der Option «--mount» erstellt wurden, erm\u00f6glicht das L\u00f6schen einer Datei au\u00dferhalb des Containers bei der Verarbeitung eines speziell gestalteten Dockerfiles. Die Schwachstelle wurde in BuildKit 0.12.5 behoben.\n
CVE-2024-23653 — ein Fehler in der API-Implementierung in BuildKit erm\u00f6glicht die Ausf\u00fchrung des Containers mit erh\u00f6hten Rechten, ungeachtet des Status der Konfiguration security.insecure. Die Schwachstelle wurde in BuildKit 0.12.5 behoben.\n
CVE-2024-23650 — ein b\u00f6sartiger Client oder Frontend von BuildKit kann zu einem Absturz des Hintergrundprozesses von BuildKit f\u00fchren. Die Schwachstelle wurde in BuildKit 0.12.5 behoben.\n
CVE-2024-24557 — die M\u00f6glichkeit der Cache-Kontamination in Moby, einer Komponente zur Erstellung spezialisierter Systeme zur Container-Isolierung. Bei der Verarbeitung eines speziell gestalteten Container-Images kann es erreicht werden, dass Daten in den Cache geschrieben werden, die in sp\u00e4teren Phasen des Builds verwendet werden k\u00f6nnen. Die Schwachstelle wurde in Moby 25.0.2 und 24.0.9 behoben. <\/ul>\n