Schwachstelle: runc process.cwd und Ausbruch aus fds-Containern (CVE-2024-21626)

Snyk hat eine Schwachstelle in allen Versionen von runc <=1.1.11 entdeckt, wie sie von der Docker-Engine und anderen Containerisierungs-Technologien wie Kubernetes verwendet werden. Die Ausnutzung dieser Schwachstelle kann dazu führen, dass Container in das zugrunde liegende Host-Betriebssystem entkommen, entweder durch die Ausführung eines bösartigen Images oder durch die Erstellung eines Images mit eines bösartigen Dockerfile oder einem Upstream-Image (d. h. bei Verwendung von FROM). Diesem Problem wurde die CVE-2024-21626 zugewiesen.

Wie funktioniert CVE-2024-21626?

Demo 1: Container-Ausbruch über docker build. Was Sie hier sehen, ist der Exploit von docker build, um aus dem Container auszubrechen und über einen beliebigen Lese- (in diesem Beispiel die Datei /etc/shadow des Hosts) und Schreibzugriff (in diesem Beispiel die Erstellung einer DOCKER_BUILD_BREAKOUT-Datei) auf das Dateisystem des Hosts zuzugreifen.

Demo 2: Container-Ausbruch über docker run. Was Sie hier sehen, zeigt, wie das Ausführen eines bösartigen Docker-Images, das auf derselben Schwachstelle basiert, in ähnlicher Weise zum Ausbruch des Docker-Containers auf das Host-Betriebssystem führen kann.

Die Schwachstelle entsteht durch die Reihenfolge der Operationen bei der Anwendung der Anweisung WORKDIR, die im Dockerfile definiert ist. WORKDIR definiert das anfängliche Arbeitsverzeichnis aller Prozesse, die durch den Dockerfile erstellt werden, wie z. B. diejenigen, die zur Erstellungszeit mit der Direktive RUN ausgeführt werden und diejenigen, die zur Laufzeit mit den Anweisungen CMD oder ENTRYPOINT laufen. Das bereitgestellte Verzeichnis wird mit chdir eingegeben, bevor bestimmte Dateideskriptoren des privilegierten Host-Verzeichnisses geschlossen wurden. Es ist möglich, einen dieser privilegierten Dateideskriptoren über das Verzeichnis /proc/self/fd/ als Argument für chdir anzugeben, wodurch der Zugriff auf den privilegierten Dateideskriptor auch dann noch möglich ist, wenn der Dateideskriptor selbst während des normalen Betriebs geschlossen wird, bevor die Übergabe an den definierten Dockerfile-Befehl erfolgt, entweder beim Build oder zur Laufzeit.

Bei einem erfolgreichen Angriff stellt der jetzt ausgeführte Prozess sicher, dass das aktuelle Verzeichnis ein Host-Verzeichnis ist, und durchläuft die Host-Verzeichnisstruktur, um auf das vollständige Host-Root-Dateisystem zuzugreifen. Standardmäßig sind die Zugriffsrechte dieselben wie die der verwendeten Containerisierungslösung, z. B. Docker Engine oder Kubernetes. In der Regel handelt es sich dabei um den Root-Benutzer, sodass es möglich ist, vom Festplattenzugriff bis zur vollständigen Ausführung von Host-Root-Befehlen zu gelangen.

Wie Sie CVE-2024-21626 entschärfen

runc hat diese Schwachstelle entschärft, indem es sichergestellt hat, dass das in der Anweisung WORKDIR angegebene Verzeichnis im Root-Dateisystem des Containers vorhanden ist. runc hat außerdem zusätzliche Härtungsschritte implementiert, um sicherzustellen, dass die Dateideskriptoren des privilegierten Host-Verzeichnisses unmittelbar nach der Verwendung ordnungsgemäß geschlossen werden.

Snyk empfiehlt, sofortige Maßnahmen gemäß dem runc advisory zu ergreifen, um diese Schwachstelle zu entschärfen. Die Version runc 1.1.12 enthält Patches für dieses Problem. Technologien, die runc bündeln, sollten ebenfalls auf die entsprechenden gepatchten Versionen aktualisiert werden. Bei gehosteten Lösungen (z. B. verwaltete Kubernetes-Dienste von beliebten Cloud Providern) sollten Sie die Herstellerhinweise befolgen bzw. umsetzen.

Bewertung des Risikos

Diese Schwachstelle hängt davon ab, dass ein bösartiger Container in einer anfälligen Infrastruktur läuft oder gebaut wird. Aufgrund der Art dieser Schwachstelle ist die Erkennung schwierig und erfordert eine Laufzeit für eine möglichst genaue Erkennung. Da unsere bestehenden Snyk-Produkte nicht mit der Laufzeit der Anwendung arbeiten, haben wir zwei Tools entwickelt, um die Erkennung dieser Sicherheitslücke zu ermöglichen.

Erkennung zur Laufzeit

Das neue Helios-Team bei Snyk hat ein eBPF-basiertes Laufzeiterkennungs-Tool für diese Schwachstelle entwickelt, das unter leaky-vessels-runtime-detector zu finden ist und unter der Apache-2.0-Lizenz veröffentlicht wurde. eBPF ist ein häufig verwendeter Instrumentierungs-Mechanismus, der in viele moderne Linux-Kernel eingebaut ist.

Dieses Tool kann einen laufenden Container identifizieren, der versucht, diese Schwachstelle in der zugrunde liegenden Infrastruktur auszunutzen und den zugrunde liegenden Host zu gefährden. Beachten Sie, dass dieses Tool den Exploit dieser Schwachstelle nicht verhindern kann, sondern nur vor der Gefährdung warnt.

Auch wenn wir Ihnen dringend empfehlen, Ihre Container-Infrastruktur zu aktualisieren, können Sie mit diesem Tool möglicherweise Ihr Risiko oder Ihre Gefährdung einschätzen, wenn eine Aktualisierung nicht sofort möglich ist. Unternehmen sollten sich bei ihrem Provider für die Container-Infrastruktur erkundigen, ob die Infrastruktur gepatcht wurde.

Installation und Verwendung

Um unser Tool zur statischen Erkennung zu installieren und zu verwenden, gehen Sie bitte wie folgt vor:

1. Klonen Sie das Repository unter https://github.com/snyk/leaky-vessels-dynamic-detector

2. Erstellen Sie das Go-Binary mit go build.

3. Starten Sie den Detektor in Ihrer CI-Umgebung mit: sudo ./ebpf-detector

Weitere Einzelheiten finden Sie in der Datei README.md.

Statische Analyse

Für den Fall, dass Sie es vorziehen, kein externes Binary auf Ihrem Host oder in Ihrer CI/CD-Pipeline laufen zu lassen, haben wir auch einen statischen Analysedetektor entwickelt, der unter https://github.com/snyk/leaky-vessels-static-detector zu finden ist und der Dockerfiles analysiert und potenzielle Exploit-Versuche kennzeichnet.

Dieses Tool untersucht Images, indem es die Anweisung FROM analysiert oder direkt den lokalen Docker-Daemon oder öffentliche Container-Registrierungen wie Dockerhub oder GCR abfragt. Der Image-Verlauf enthält zwar nicht alle Anweisungen, die eine vollständige Dockerfile enthalten würde, aber sie zeigt die Anweisungen WORKDIR und ONBUILD des übergeordneten Images an, die auf potenziell schädliche Images hinweisen können.

Dies ist nützlich, um sich vor Fällen zu schützen, in denen ein Basis-Image eines Drittanbieters kompromittiert wurde und versucht, die Befehle run oder build des Child-Images auszunutzen. Der statische Ansatz hat eine höhere Falsch-Positiv-Rate (Rauschen), insbesondere bei Exploits, die das --mount flag verwenden, kann aber Images finden, die eine weitere Untersuchung wert sind.

Das Snyk-Team hat Ad-hoc-Checks von Dockerfiles aus öffentlichen Registern durchgeführt, basierend auf den Images, die unserer Meinung nach am häufigsten verwendet werden. Unsere Untersuchung ist zwar nicht erschöpfend, aber wir haben keine Hinweise darauf gefunden, dass diese Schwachstellen bereits ausgenutzt wurden. Snyk empfiehlt Ihnen, Ihre eigene Umgebung weiterhin zu überwachen und Ihre Container zu überprüfen, bis Patches zur Verfügung gestellt und bereitgestellt werden.

Wie immer ist es eine gute Praxis, gut gepflegte übergeordnete Images aus vertrauenswürdigen Quellen zu verwenden und mit den neuesten Versionen auf dem Laufenden zu bleiben – einschließlich des Löschens von Build-Caches und der Überprüfung der Herkunft der übergeordneten Images.

Installation und Verwendung

Um unser Tool zur statischen Erkennung zu installieren und zu verwenden, gehen Sie bitte wie folgt vor:

1. Klonen Sie das Repository unter https://github.com/snyk/leaky-vessels-static-detector

2. Erstellen Sie das Go-Binary mit go build.

3. Starten Sie den Detektor mit: ./static-detector dockerfile -f [PATH_TO_DOCKERFILE].

4. Weitere Ausführungsoptionen entnehmen Sie bitte der Datei README.md.

CVE-2024-21626: Zusammenfassung und Ratschläge

Diese Schwachstelle in Containern hat einen hohen Schweregrad und kann jede zugrunde liegende Host-Infrastruktur, auf der Container ausgeführt oder erstellt werden, beschädigen.

Snyk empfiehlt Ihnen, alle Instanzen von runc auf Version 1.1.12 oder höher zu aktualisieren, ebenso wie jede Software, die von runc abhängt. Stellen Sie außerdem sicher, dass Sie alle Herstellerhinweise zu diesem Problem befolgen, da Container-Hosting-Dienste und -Infrastrukturen betroffen sein könnten.

Snyk hat in seinen Untersuchungen auch mehrere andere Schwachstellen in Containern aufgedeckt, denen CVEs zugeordnet sind: CVE-2024-23652, CVE-2024-23651, und CVE-2024-23653. Sie können die Zusammenfassung unserer Erkenntnisse über alle CVEs hier lesen.

Dieser Artikel dient nur zu Informationszwecken. Snyk ist nicht verantwortlich für Fehler oder Auslassungen oder für die Ergebnisse, die sich aus der Verwendung dieser Informationen ergeben.