Schwerwiegende Sicherheitslücke in runC ermöglicht Rechteausweitung zu Root in Docker und Kubernetes

Eine von Adam Iwaniuk und Borys Popławski entdeckte Sicherheitslücke in der Open-Source-Software runC wurde am 11. Februar 2019 offengelegt und als CVE-2019-5736 beschrieben.

Die Schwachstelle betrifft mehrere Container-Engines wie Docker und Kubernetes. Sie befindet sich in einer zentralen Komponente der Container-Engines und ermöglicht es Containern, ihre isolierte Umgebung zu verlassen und Zugriff auf den Hostserver zu erhalten, auf dem sie ausgeführt werden. Dadurch können sie auch auf andere Container zugreifen und Root-Rechte auf dem Host erlangen.

Dieses Sicherheitsproblem folgt auf eine kritische Schwachstelle, die am 3. Dezember 2018 gemeldet wurde. Dabei wurde festgestellt, dass eine Kubernetes-API-Komponente für Angriffe anfällig ist, mit denen beliebige Befehle in laufenden Containern ausgeführt werden können.

William Bowling teilte auf Twitter ein Video, das den Proof-of-Concept-Angriff in Aktion zeigt. Die runC-Binärdatei auf dem Hostserver wird von einem laufenden Container aus durch eine mit einer Hintertür versehene Version ersetzt:

Iwaniuk und Popławski veröffentlichten heute einen Blogbeitrag, der den runC-Angriff im Detail beschreibt und erläutert, was sie zu ihrer Recherche inspirierte, die zur Entdeckung der Schwachstelle führte.

Die Schwachstelle

Wie kann diese Schwachstelle ausgenutzt werden? Christian Brauner schrieb über die Bedeutung, die Semantik privilegierter und nicht privilegierter Container zu verstehen:

Was wir mit einem privilegierten Container meinen, ist ein Container, in dem die Semantik der ID 0 innerhalb und außerhalb des Containers unter sonst gleichen Bedingungen identisch ist. Ich sage „unter sonst gleichen Bedingungen“, weil die Verwendung von LSMs, seccomp oder anderen Sicherheitsmechanismen die Bedeutung der ID 0 innerhalb und außerhalb des Containers nicht verändert. Ein Ausbruch, der beispielsweise durch einen Fehler in der Laufzeitumgebung verursacht wird, verschafft Ihnen Root-Zugriff auf den Host.

Ein nicht privilegierter Container ist ein Container, in dem die Semantik der ID 0 innerhalb des Containers sich von der Semantik der ID 0 außerhalb des Containers unterscheidet. Ein Ausbruch, der beispielsweise durch einen Fehler in der Laufzeitumgebung verursacht wird, verschafft Ihnen standardmäßig keinen Root-Zugriff auf den Host. Das sollte nur möglich sein, wenn die Implementierung des User-Namespace im Kernel einen Fehler aufweist.

Der hohe Schweregrad und die Auswirkungen dieser Schwachstelle sind darauf zurückzuführen, dass Docker-Container standardmäßig als privilegierte Container ausgeführt werden. Hinzu kommt die Art und Weise, wie die runC-Befehlszeilen-Binärdatei verwendet wird.

Wie Brauner erklärt, führen Implementierungen der Container-Technologie wie Docker die runC-Binärdatei bei jedem Containerbefehl aus. Anschließend wird der runC-Prozess beendet. Dadurch kann ein bösartiger Container die runC-Binärdatei verändern, sodass bei allen folgenden Containerbefehlen effektiv die modifizierte runC-Binärdatei ausgeführt wird.

Das unterscheidet sich deutlich von der Funktionsweise von LXC, bei der ein ähnlicher Prozess nach der Ausführung von Containerbefehlen nicht beendet wird:

LXC kann nicht über ein bösartiges Image angegriffen werden, da der Überwachungsprozess (ein Singleton pro Container) während des gesamten Lebenszyklus des Containers aktiv bleibt. Da der Kernel keine Änderungen an laufenden Binärdateien zulässt, kann ein Angreifer diese nicht beschädigen. Wird der Container heruntergefahren oder beendet, wird der angreifende Task beendet, bevor er Schaden anrichten kann. Erst wenn der letzte im Container laufende Prozess beendet wurde, wird auch der Überwachungsprozess beendet. Das bedeutet: Wenn Sie privilegierte OCI-Container über unsere OCI-Vorlage mit LXC ausführen, sind Sie nicht durch bösartige Images gefährdet. Es bleibt lediglich der Angriffsweg über die angehängte Binärdatei.

Diese Schwachstelle erinnert außerdem an das Sicherheitsprinzip geringstmöglicher Berechtigungen und die Best Practice, dafür zu sorgen, dass das schwächste Glied nicht zur Grundlage für weitergehende Rechteausweitungen und Exploits wird.

Sicherheitsbedenken und verantwortungsvolle Offenlegung

Das grundlegende Prinzip der Container-Technologie ist die Isolation verschiedener Apps und Services. Wenn diese nicht gewährleistet ist, schrillen zweifellos die Alarmglocken.

Angriffe auf die Software-Supply-Chain sind in der Container-Welt nichts Neues und haben auch bei Anwendungsbibliotheken für Schlagzeilen gesorgt. Einem 2018 auf threatpost veröffentlichten Artikel zufolge ergab eine Recherche des Kromtech Security Center, dass mehr als siebzehn bösartige Container aktiv für illegales Kryptomining eingesetzt wurden. Die bösartigen Images wurden auf Docker Hub, der offiziellen öffentlichen Registry für Docker-Images, gehostet und später entfernt.

In einem Update zur runC-Schwachstelle teilte Aleksa Sarai, Maintainer von runC und leitender Softwareentwickler bei SUSE Linux, gestern mit, dass auch eine andere Linux-Container-Technologie namens LXC anfällig für die oben genannte CVE ist, allerdings über einen anderen Angriffsweg.

Außerdem wurde angekündigt, dass der Exploit-Code am 18. Februar veröffentlicht wird, damit getestet und überprüft werden kann, ob die Sicherheitslücke erfolgreich geschlossen wurde. Nutzer wurden dazu aufgefordert, Patches verantwortungsvoll einzuspielen.

Falls Sie Snyk noch nicht ausprobiert haben, können Sie unsere CLI verwenden, um Tests lokal auszuführen, oder Ihre Quellcode-Repositories verbinden, um automatisierte Scans und Behebungen zu ermöglichen. Wenn Sie Snyk bereits nutzen, sollten Sie wissen, dass wir diese Schwachstelle in unserer Datenbank erfassen.

Wir freuen uns, dass die Open Container Initiative (OCI) ihrer Registry eine SECURITY.md hinzugefügt hat, um Forschenden Richtlinien für die verantwortungsvolle Offenlegung von Sicherheitsproblemen bereitzustellen. Wir hatten dies bereits in der Vergangenheit empfohlen – ebenso wie weitere Richtlinien für ein sicheres Quellcode-Management, die Sie in unseren GitHub Security Best Practices finden.

Wichtigste Erkenntnisse

• Führen Sie keine nicht vertrauenswürdigen und ungeprüften Container-Basis-Images aus.

• Wenden Sie stets das Prinzip der geringstmöglichen Berechtigungen an und entscheiden Sie sich für nicht privilegierte Container.

• Scannen Sie Open-Source-Bibliotheken auf Schwachstellen, um ungepatchte Server zu finden, die möglicherweise noch von dieser CVE betroffen sind.