Leaky Vessels: Sicherheitslücken bei Docker und runc-Containern (Januar 2024)

Der Snyk-Sicherheitsforscher Rory McNamara vom Team der Snyk Security Labs hat vier Schwachstellen – die sogenannten Leaky Vessels (Undichte Container) – in zentralen Komponenten der Container-Infrastruktur identifiziert, die Container-Ausbrüche ermöglichen. Ein Angreifer könnte diese Container-Escapes nutzen, um aus dem Container heraus unbefugten Zugriff auf das zugrunde liegende Host-Betriebssystem zu erlangen. Sobald ein Angreifer Zugriff auf das zugrunde liegende Host-Betriebssystem erlangt hat, könnte er möglicherweise auf alle Daten auf dem System zugreifen, einschließlich sensibler Daten (Anmeldedaten, Kundeninformationen usw.), und weitere Angriffe starten. Nach der Entdeckung und Überprüfung leitete das Team von Security Labs den Prozess zur verantwortungsvollen Offenlegung der Schwachstellen ein. Zunächst wurde Docker benachrichtigt, das nach der Überprüfung eine der Schwachstellen an die Open Source Sicherheitsgruppe runc weiterleitete. Der Zeitplan für die Bekanntgabe der Schwachstellen ist unten aufgeführt. 

Da diese Schwachstellen weitverbreitete Low-Level-Container-Engine-Komponenten und Container-Build-Tools betreffen, empfiehlt Snyk den Anwendern dringend, bei den Anbietern von Container-Build- und Laufzeitsystemen, einschließlich Docker, Kubernetes-Anbietern, Cloud-Container-Diensten und Open Source-Communities, nach Aktualisierungen zu suchen. Sie sollten Systeme mit Container-Engines und Container-Build-Tools aktualisieren, sobald Fixes von Ihren Providern veröffentlicht werden.

Über die Schwachstellen

Am 31. Januar 2024 meldeten die Maintainer von runc, einem CLI-Tool zum Spawnen und Ausführen von Containern unter Linux, eine Schwachstelle (CVE-2024-21626), die einen Ausbruch von Containern in der Reihenfolge der Operationen rund um den Befehl WORKDIR ermöglicht. Ein Exploit dieser Schwachstelle kann dazu führen, dass eine Container-Escape-Schwachstelle im zugrunde liegenden Host-Betriebssystem ausbricht. Dies könnte durch Ausführen eines bösartigen Images oder durch Erstellen eines Container-Images unter Verwendung einer bösartigen Dockerfile oder eines Upstream-Images (d. h. bei Verwendung von FROM) geschehen. Die gepatchte Version, runc 1.1.12, wurde am 31. Januar 2024 gegen 3:00 PM EST veröffentlicht, wie die Maintainer mitteilen.

Weitere Details zu dieser Schwachstelle finden Sie in diesem high-level-Blog, in dem die runc- Schwachstelle selbst beschrieben wird. Darüber hinaus haben Rory und das Team von Snyk Labs drei weitere Container-Escape-Schwachstellen identifiziert, insgesamt also vier Schwachstellen, die im Folgenden mit Links zu den entsprechenden CVEs und Übersichtsblogs aufgeführt sind:

• CVE-2024-21626: runc process.cwd & leaked fds container breakout

• CVE-2024-23651: Buildkit Mount Cache Race

• CVE-2024-23653: Buildkit GRPC SecurityMode Privilege Check

• CVE-2024-23652: Buildkit Build-time Container Teardown Arbitrary Delete

Von Snyk erhältliche Tools zum Aufspüren dieser Sicherheitslücken

Diese Schwachstellen betreffen eher die zugrunde liegende Container-Infrastruktur und die Build-Tools als die Container-Images. Snyk Container wurde entwickelt, um Entwicklerinnen/Entwicklern bei der Beseitigung von Schwachstellen in ihren Container-Images zu helfen. Daher liegen diese Schwachstellen außerhalb des Bereichs, auf den die Produkte von Snyk derzeit ausgelegt sind. Snyk hat jedoch zwei Open-Source-Tools entwickelt, die als Referenz-Implementierungen für die Erkennung von Exploit-Versuchen dienen. Bitte beachten Sie, dass diese Tools nicht unter Snyk Support fallen, sondern eher als Beispiele für die Community dienen. 

Erkennung von Exploits zur Laufzeit (leaky-vessels-runtime-detector)

Das neue Helios-Team bei Snyk hat ein 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 wird. Dieses eigenständige Tool, das unter der Apache-2.0-Lizenz veröffentlicht wurde, bietet eine Referenz-Implementierung zum Aufspüren der Sicherheitslücken während ihrer Ausführung. Das Tool bindet eBPF-Hooks an Funktionen auf Kernel- und Benutzerebene sowie an einen Paketdetektor. Dadurch können sie Aufrufe von Container-Builds und laufenden Containern melden, wenn sie mit Mustern übereinstimmen, die auf einen möglichen Exploit-Versuch hindeuten. Beachten Sie, dass nicht alle Distributionen oder Versionen von Linux eBPF unterstützen, und es ist unwahrscheinlich, dass Kundinnen und Kunden diese Funktion bei Cloud Service Providern nutzen können.

Statische Container-Befehlserkennung (leaky-vessels-static-detector)

Das zweite Tool ist ein statisches Analyseprogramm, leaky-vessels-static-detector, das ebenfalls unter der Apache-2.0-Lizenz veröffentlicht wurde. Es scannt Dockerfiles und Image-Layer, um Befehle zu erkennen, die den Eindruck erwecken, dass sie die Schwachstellen ausnutzen wollen. Das Tool liefert eine Ausgabe im JSON-Format, die anzeigt, ob es fragwürdige Befehle entdeckt hat. Es ist wichtig, zu wissen, dass jeder Treffer manuell überprüft werden muss, um festzustellen, ob es sich tatsächlich um Exploits handelt und nicht um die legitime Verwendung von Container-Befehlen.

Wir geben diese beiden Tools als Open Source frei, um der Community Referenz-Implementierungen für die Erkennung potenzieller Exploit-Versuche zur Verfügung zu stellen. Das Laufzeit-Tool bietet wahrscheinlich ein höheres Maß an Vertrauen in die Ergebnisse als das statische Tool. Angesichts der Art der Exploits und der Build-Befehle werden jedoch beide Tools wahrscheinlich einige falsch-negative und falsch-positive Ergebnisse liefern. Die Community kann die Tools als Beispiele verwenden, um eigene Tools zu erstellen, oder die Tools in ihren Umgebungen ausführen. Wichtig ist, dass diese Tools weder die Schwachstellen beheben noch deren Exploit verhindern, aber sie helfen, Risikobereiche zu identifizieren. Am klügsten ist es, wenn die Kundinnen und Kunden die betroffenen Container- und Orchestrations-Plattformen aktualisieren, sobald Patches verfügbar sind. 

Gibt es aktive Exploits?

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. Dies ist nicht erschöpfend, aber bei unseren Recherchen haben wir 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. Angesichts der Art der Probleme hat Snyk zwei Open-Source-Tools entwickelt, die oben beschrieben sind: ein dynamisches Tool, das die Erkennung von Aktionen aus den Schwachstellen zur Laufzeit demonstriert, und ein statisches Tool zum Scannen von Images und Dockerfiles, das als Indikator für einen möglichen Exploit dient.

So bereiten Sie sich auf die Behebung vor

Die Abhilfemaßnahmen sollten auf der Ebene der Infrastruktur und der Code-Tools durchgeführt werden. Achten Sie ggf. auf Ankündigungen oder Veröffentlichungen des Providers oder Anbieters Ihrer Container-Build- und Orchestrierungssysteme.  Sie müssen wahrscheinlich Ihre Docker-Daemons und Kubernetes-Bereitstellungen sowie alle Container-Build-Tools aktualisieren, die Sie in CI/CD-Pipelines, auf Build-Servern und auf den Workstations Ihrer Entwickler/innen verwenden. Es ist auch wichtig, vorhandene Container mit Tools wie den von Snyk entwickelten zu überprüfen, um festzustellen, ob Ihre Orchestrierungs-Knoten oder Ihre Build-Infrastruktur bereits betroffen sind.

Hier sind einige Aktualisierungen, die wir von weitverbreiteten Tools und Diensten gesammelt haben:

Anatomie einer Enthüllung

Der Zeitplan für Schwachstellen kann sehr komplex sein, insbesondere wenn mehrere Unternehmen beteiligt sind. Es ist wichtig, dass mit den Enthüllungen verantwortungsvoll umgegangen wird, damit böswillige Akteure nicht von ihnen erfahren, bevor Fixes verfügbar sind. 

In diesem Fall wurden die Schwachstellen erstmals vor zwei Monaten entdeckt. Zu diesem Zeitpunkt begann Snyk mit dem Prozess der verantwortungsvollen Offenlegung. Hier ist eine Zeitleiste mit einigen wichtigen Meilensteinen des Prozesses.

Jeder Schritt auf dem Weg dorthin beinhaltet die Zusammenarbeit innerhalb und zwischen Organisationen – nicht nur kommerziellen Organisationen, sondern oft auch den Teams, die die Komponenten warten, die sich oft aus einem Querschnitt der Community zusammensetzen.

Über das Security Labs Team von Snyk

Das Security Labs Team von Snyk hat dazu beigetragen, dass mehr als 3.200 Schwachstellen in wichtigen Paketen in einer Vielzahl von Ökosystemen aufgedeckt wurden. Wir arbeiten eng mit den Maintainern von Open-Source-Paketen zusammen, um sicherzustellen, dass alle Schwachstellen verantwortungsvoll und effizient behoben werden. Unsere Sicherheitsexpertise ist einer der Gründe dafür, dass so viele große Namen in der Sicherheitsbranche Snyk vertrauen. Wenn Sie eine Schwachstelle finden und nicht wissen, wie Sie diese auf verantwortungsvolle Weise melden sollen, füllen Sie dieses Formular aus und unsere Teams können Ihnen helfen.

War Snyk betroffen?

Informationen darüber, wie Snyk mit Schwachstellen in unserer eigenen Umgebung umgeht, finden Sie im Snyk Trust Portal.

Zusammenfassung

Wir werden diesen Blog aktualisieren, sobald wir mehr erfahren, und wir werden am Dienstag, den 6. Februar um 11:00 Uhr ET ein Webinar zu Leaky Vessels Container Breakout Vulnerabilities – What You Need to Know abhalten. Die technischen Experten von Snyk geben einen ausführlichen technischen Überblick über eine der Leaky-Vessels-Schwachstellen, deren Ursache, wie sie ausgenutzt werden kann und vor allem, wie sie durch Upgrades und Überwachung entschärft werden kann.

Wenden Sie sich an uns, wenn Sie Fragen zu den Schwachstellen haben. Für die Open-Source-Tools erstellen Sie ein GitHub-Ticket für die jeweiligen Tools (dynamic-detector und static-detector) oder melden Sie sich auf dem Snyk Community Discord. 

Weitere Informationen zu Leaky Vessels finden Sie hier:

• Leaky Vessels – runc Vulnerability Explained (YouTube)

• Leaky Vessels im Detail: Die Flucht aus Docker – ein Syscall nach dem anderen (Blog)

• Hands-on-Lektion: runc process.cwd Container-Schwachstelle (Snyk Learn)

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.

Änderungsprotokoll

• 31. Januar 2024, 15:00 Uhr ET: Erste Veröffentlichung

• 31. Januar 2024, 18:00 Uhr. ET: CVE-URLs hinzugefügt; Aktualisierungen von AWS, containerd, GCP, Docker und Ubuntu hinzugefügt

• 7. Februar 2024, 13:00 Uhr ET: YouTube-Video und Deep-Dive-Links zum Abschnitt Zusammenfassung hinzugefügt

• 8. Februar 2024, 10:00 Uhr ET: Snyk Learn-Lektion zum Abschnitt „Zusammenfassung“ hinzugefügt