Runc: Sicherheitslücke ermöglicht Übernahme von Container-Host
Eine Sicherheitslücke ermöglicht es, dass Software aus einem Container ausbricht. Die Ausführungsumgebung Runc, mit der Container gestartet werden, kann überschrieben und so der Host übernommen werden. Docker und viele andere Lösungen sind verwundbar.

Die Entwickler von Runc, der standardisierten Ausführungsumgebung für Container, haben eine Sicherheitslücke (CVE-2019-5736) geschlossen, die die Isolation der im Container gestarteten Software aushebelt. Runc-Entwickler Aleksa Sarai schreibt, dass die Sicherheitslücke es einem Container erlaubt, die Runc-Software selbst auszutauschen und damit das Host-System zu kompromittieren, in dem der Container läuft. Die Lücke betrifft die populäre Container-Software Docker, aber auch andere Containerlösungen, die auf Runc setzen.
Eigentlich sollten Container genau dazu dienen, Software in isolierten Umgebungen auszuführen. Eine Sicherheitslücke in einem Container soll gerade nicht dazu führen, dass das System selbst angegriffen werden kann. Durch die Sicherheitslücke in Runc wird also eine zentrale Eigenschaft von Containern untergraben.
Die Details der Lücke hat Sarai noch nicht bekanntgegeben. Aus der Beschreibung des Patches auf Github geht jedoch hervor, dass die Lücke mit dem Proc-Dateisystem zusammenhängt. Über den Pfad /proc/self/exec kann in Linux-Systemen eine Applikation auf ihre eigene ausführbare Datei zugreifen, dies wird hier wohl ausgenutzt, um die Runc-Datei auszutauschen.
Nutzer-Namespaces falsch benutzt
Ob ein System tatsächlich verwundbar ist, hängt von einigen wichtigen Details ab. Wenn etwa die Nutzer-Namespaces so verwendet werden, dass der Root-Nutzer des Hosts nicht in den Container gemappt wird, ist die Lücke nicht ausnutzbar. Die Technik der Nutzer-Namespaces ermöglicht es eigentlich, dass ein Prozess innerhalb des Containers mit der ID 0 des Root-Nutzers ausgeführt wird. Der Prozess hat so scheinbar volle Systemkontrolle. Allerdings lässt sich für diesen Prozess auf dem Hostsystem dann dank der Namespaces eine Nutzer-ID mit weniger Rechten vergeben.
Der für die Sicherheitslücke ausgenutzte Fehler besteht nun offenbar darin, durch eine falsche Verwendung der Nutzer-Namespaces dem Prozess mit Root-Rechten im Container auch auf dem Hostsystem Root-Rechte einzuräumen. So ist es dann natürlich leicht, den im Container kontrollierten Prozess auch außerhalb des Containers im Hostsystem zu manipulieren.
Laut den Entwicklern der Containerimplementierung LXC reicht es dazu offenbar aus, wenn eine Binärdatei im Container einfach zurück auf Runc im Host verweist. Zusätzlich dazu sind aber noch einige weitere Tricks notwendig, um Runc erfolgreich zu manipulieren.
Viele verschiedene Werkzeuge betroffen
Einen Exploit, der die Lücke ausnutzt, will Sarai in einer Woche veröffentlichen. Neben Docker sind auch andere Containerlösungen verwundbar, da Runc ein Standardwerkzeug für viele weitere Techniken ist. Dazu gehören CRI-O und Kubernetes oder auch kommerzielle Lösungen wie etwa Red Hats Openshift oder Suses Container-Plattformen. Für Amazons Web Services stehen bereits Erklärungen zu der Lücke bereit ebenso wie für Googles Cloud Platform.
Die alternative Containertechnik LXC, die Runc nicht verwendet, ist ebenfalls für eine Variante des Angriffs verwundbar. Das LXC-Projekt betrachtet dies aber nicht als Sicherheitslücke, da LXC Container mit Root-Rechten prinzipiell nicht als vertrauenswürdig einstuft. Laut Sarai haben auch die Entwickler von Apache Mesos bekanntgegeben, dass die Software für die Lücke verwundbar ist. Sarai vermutet außerdem, dass dies auch für weitere Containerlösungen gilt.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Ich habe schon vor fünf Jahren LXC rootless Clients eingesetzt, allerdings als OS Client...
ergo? Services, die priv Container erfordern, läßt man in type I VMM und nur unpriv auf...