Hinweis perev. : Gestern Abend hat Aleksa Sarai, eine leitende Containeringenieurin bei SUSE Linux, der Oss-Sec-Mailingliste eine kritische Sicherheitslücke in Runc / LXC mitgeteilt, die es einem Angreifer mit Zugriff auf einen isolierten Container ermöglichen könnte, Root-Rechte auf dem Hostsystem zu erlangen. Da das Problem in der Laufzeitimplementierung des Referenzcontainers - runc - identifiziert wurde, betrifft es zahlreiche Containersysteme, einschließlich Docker / Moby, Podman , cri-o (und Kubernetes selbst). Details werden unten in Form der Übersetzung der Nachricht eines Ingenieurs in eine Mailingliste dargestellt.Ich bin einer der Runc-Betreuer (die zugrunde liegende Container-Laufzeit, die von Docker, Cri-O, Containerd, Kubernetes usw. verwendet wird). Kürzlich wurde bekannt, dass wir eine Sicherheitslücke überprüft und gepatcht haben.
Forscher, die die Sicherheitsanfälligkeit entdeckt haben:
- Adam Iwaniuk;
- Borys Popławski.
Darüber hinaus entdeckte Aleksa Sarai (d. H. Ich), dass der LXC auch von einer komplexeren Version dieser Sicherheitsanfälligkeit betroffen ist.
Kurzer Rückblick
Die Sicherheitsanfälligkeit ermöglicht es einem böswilligen Container (mit minimaler Benutzerinteraktion), die Runc-Host-Binärdatei zu überschreiben und somit Code mit Root-Rechten auf dem Host auszuführen. Der Grad der Benutzerinteraktion ist so, dass Sie Befehle (es spielt keine Rolle, ob der Angreifer den Befehl steuert) mit Root-Rechten innerhalb des Containers in einem der folgenden Kontexte ausführen können:
- Erstellen eines neuen Containers aus einem von einem Angreifer kontrollierten Bild;
- Verbindung (
docker exec ) zu einem vorhandenen Container, auf den der Angreifer zuvor Schreibzugriff hatte.
Diese Sicherheitsanfälligkeit wird
weder durch die AppArmor-Standardrichtlinie noch durch die SELinux-Standardrichtlinie in Fedora *
blockiert (da die Containerprozesse so aussehen, als hätten sie mit
container_runtime_t ). Es wird
jedoch durch die korrekte Verwendung von Benutzernamensräumen
blockiert (wobei das Stammverzeichnis des Hosts nicht dem Benutzernamensraum des Containers zugeordnet ist).
Der CVSSv3-Vektor (mit einer Bewertung von 7,2) ist wie folgt:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:HDas
Problem ist CVE-2019-5736 zugeordnet .
* Das Problem betrifft nur das moby-engine Paket in Fedora. Das docker Paket ist wie podman vor seiner Operation geschützt, da es Containerprozesse als container_t startet.Patches
Ich
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch den entsprechenden Patch an, um das Problem zu beheben (
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch ). Es basiert auf dem
HEAD Zweig, obwohl sich der Code in
libcontainer/nsenter/ so selten ändert, dass der Patch höchstwahrscheinlich für fast jede alte Version der Runc-Codebasis gilt, mit der Sie sich befassen.
Bitte beachten Sie, dass der
Patch , den ich an den Runc-Master-Zweig weitergebe, eine modifizierte Version dieses Patches ist, obwohl sie funktional identisch sind (wenn Sie Ihre Dateien noch nicht mit dem angehängten Patch gepatcht haben, empfehlen wir die Verwendung der Upstream-Version).
Sekundärer Exploit-Code
Einige Anbieter haben einen Exploit-Code angefordert, um sicherzustellen, dass Patches das Problem lösen. Da das Problem sehr schwerwiegend ist (insbesondere für Anbieter öffentlicher Clouds), haben wir uns entschlossen, einen solchen Code bereitzustellen. Der Exploit, den ich geschrieben habe, ist allgemeiner als der von den Forschern bereitgestellte Originalcode und funktioniert für den LXC (es sind keine starken Änderungen erforderlich, um auf andere anfällige ausführbare Umgebungen angewendet werden zu können). Details zur Verwendung des Exploit-Codes finden Sie in
README .
In Übereinstimmung mit den OpenWall-Regeln wird der Exploit-Code 7 Tage nach der CRD (d. H. 18. Februar 2019)
öffentlich veröffentlicht.
Wenn Sie eine Container-Laufzeit haben, stellen Sie bitte sicher, dass diese nicht von dieser Sicherheitsanfälligkeit betroffen ist.Auswirkungen auf andere Projekte
Es sollte beachtet werden, dass ich im Verlauf der weiteren Untersuchung des Problems festgestellt habe, dass der LXC eine ähnliche Sicherheitslücke aufweist, und dass bereits ein ähnlicher
Teil unserer gemeinsamen Entwicklung beseitigt wurde. LXC ist etwas schwieriger zu bedienen, aber das Problem selbst ist das gleiche.
Eine Diskussion mit Vertretern von systemd-nspawn führte zu dem Schluss, dass sie nicht anfällig sind (da sie eine andere Methode zum Herstellen einer Verbindung zum Container für LXC und runc haben).
Vertreter von Apache Mesos haben mich ebenfalls kontaktiert und berichtet, dass sie ebenfalls anfällig sind (ich denke, dass sie einfach den Exploit-Code verwendet haben, der veröffentlicht wird). Es ist sehr wahrscheinlich, dass die meisten Containerlaufzeiten anfällig sind, wenn sie zuvor keine ungewöhnlichen Schritte unternommen haben, um ihre potenziellen Auswirkungen zu mindern.
Andere Neuigkeiten
Wir haben die Ankündigungsverteilung für zukünftige Sicherheitslücken konfiguriert: Der Beitrittsprozess wird
hier beschrieben (er basiert auf der Kubernetes-Mailingliste für Sicherheitsankündigungen). Bitte treten Sie bei, wenn Sie Laufzeiten für Container verteilen, die von runc (oder anderen OCI-Projekten) abhängen.
PS Vom Übersetzer
CVE-2019-5736-Problem in Trackern beliebter Linux-Distributionen:
... und den
Kubernetes-Blogbeitrag (
siehe Abschnitt „Was soll ich tun?“).