Eine Schwachstelle in cgroups v1, die es ermöglicht, aus einem isolierten Container auszubrechen.

Die Details der Schwachstelle (CVE-2022-0492) in der Implementierung des Ressourcenbeschränkungsmechanismus cgroups v1 im Linux-Kernel wurden aufgedeckt, die dazu verwendet werden kann, um aus isolierten Containern auszubrechen. Das Problem tritt ab dem Linux-Kernel 2.6.24 auf und wurde in den Kernel-Versionen 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 und 4.9.301 behoben. Die Veröffentlichung von Updates für Pakete in den Distributionen kann auf den folgenden Seiten verfolgt werden: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.

Die Schwachstelle wird durch einen logischen Fehler im Handler release_agent verursacht, der dazu führt, dass bei der Ausführung des Handlers mit vollständigen Rechten keine ordnungsgemäßen Prüfungen durchgeführt wurden. Die Datei release_agent wird verwendet, um das Programm zu bestimmen, das vom Kernel beim Beenden eines Prozesses in cgroup ausgeführt wird. Dieses Programm wird mit Root-Rechten und mit allen "Capabilties" im Root-Namespace ausgeführt. Es wurde angenommen, dass nur der Administrator Zugriff auf die Konfiguration von release_agent hat, jedoch beschränkten sich die Prüfungen in der Praxis darauf, dem Benutzer root Zugriff zu gewähren, was Änderungen der Konfiguration aus einem Container oder durch den root-Benutzer ohne Administratorrechte (CAP_SYS_ADMIN) nicht ausschloss.

Früher wäre eine solche Eigenschaft nicht als Schwachstelle wahrgenommen worden, aber die Situation hat sich mit dem Aufkommen von Benutzer-Namensräumen (user namespaces) geändert, die es erlauben, in Containern eigene root-Benutzer zu erstellen, die mit dem root-Benutzer der Hauptumgebung nicht in Konflikt stehen. Entsprechend reicht es aus, in einem Container mit einem eigenen root-Benutzer in einem separaten Benutzer-Identitätsraum seinen eigenen release_agent-Handler anzuschließen, der nach dem Beenden des Prozesses mit vollen Rechten der Hauptumgebung ausgeführt wird.

Standardmäßig wird cgroupfs im Container im Nur-Lese-Modus gemountet, aber es gibt keine Probleme, dieses Pseudo-Dateisystem bei Vorliegen von CAP_SYS_ADMIN-Rechten oder durch die Erstellung eines verschachtelten Containers mit separatem Benutzer-Namespace über den Systemaufruf unshare im Schreibmodus zu remounten, wobei für den erstellten Container die Rechte CAP_SYS_ADMIN verfügbar sind.

Ein Angriff kann durchgeführt werden, wenn Root-Rechte in einem isolierten Container vorhanden sind oder wenn der Container ohne das Flag no_new_privs, das den Erhalt zusätzlicher Privilegien verbietet, gestartet wird. Das System muss die Unterstützung von Benutzer-Namensräumen aktiviert haben (standardmäßig in Ubuntu und Fedora aktiviert, aber nicht in Debian und RHEL) und Zugriff auf die Root-Cgroup v1 haben (zum Beispiel startet Docker Container in der Root-RDMA-Cgroup). Ein Angriff ist auch möglich, wenn die Privilegien CAP_SYS_ADMIN vorhanden sind; in diesem Fall sind die Unterstützung von Benutzer-Namensräumen und der Zugriff auf die Root-Hierarchie der Cgroup v1 nicht erforderlich.

Neben dem Verlassen des isolierten Containers ermöglicht die Sicherheitsanfälligkeit auch Prozessen, die vom Benutzer root ohne „Capabilities“ oder von jedem Benutzer mit den Rechten CAP_DAC_OVERRIDE (für den Angriff ist der Zugriff auf die Datei /sys/fs/cgroup/*/release_agent, die root gehört, erforderlich), auf alle systemweiten „Capabilities“ zuzugreifen.

Es wird festgestellt, dass die Sicherheitsanfälligkeit nicht ausgenutzt werden kann, wenn Mechanismen wie Seccomp, AppArmor oder SELinux zum zusätzlichen Isolieren von Containern verwendet werden, da Seccomp den Zugriff auf den Systemaufruf unshare() blockiert, während AppArmor und SELinux das Einhängen von cgroupfs im Schreibmodus verhindern.

Quelle: opennet.ru