Details zur Schwachstelle (CVE-2022-0492) in der Implementierung des Ressourcenlimits von cgroups v1 im Linux-Kernel wurden offengelegt. Diese Schwachstelle kann verwendet werden, um aus isolierten Containern auszubrechen. Das Problem tritt ab Kernel-Version 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. Informationen zu Updates der Pakete in den Distributionen sind auf den folgenden Seiten verfügbar: 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 erforderliche Prüfungen beim Ausführen des Handlers mit vollständigen Berechtigungen nicht durchgeführt werden. Die Datei release_agent wird verwendet, um das Programm zu bestimmen, das vom Kernel beim Beenden eines Prozesses in einer cgroup ausgeführt wird. Dieses Programm wird mit root-Rechten und allen „Capabilities“ im Root-Namensraum gestartet. Es war vorgesehen, dass nur Administratoren Zugriff auf die Konfiguration von release_agent haben, jedoch beschränkten sich die Prüfungen tatsächlich nur auf den Zugang des root-Benutzers, was eine Änderung der Konfiguration aus einem Container oder durch einen root-Benutzer ohne Administratorrechte (CAP_SYS_ADMIN) nicht ausschloss.
Früher wurde eine solche Eigenschaft nicht als Sicherheitsanfälligkeit angesehen, aber die Situation hat sich mit der Einführung der Benutzer-Namespace für Identifikatoren geändert. Diese ermöglichen es, in Containern einzelne Root-Benutzer zu erstellen, die nicht mit dem Root-Benutzer der Hauptumgebung kollidieren. Folglich reicht es aus, in einem Container, der seinen eigenen Root-Benutzer in einem separaten Namespace hat, einen eigenen release_agent-Handler zu verbinden, der nach dem Beenden des Prozesses mit vollen Rechten der Hauptumgebung ausgeführt wird.
Standardmäßig wird cgroupfs im Container im Nur-Lese-Modus eingebunden, aber es gibt keine Probleme, dieses Pseudodateisystem im Schreibmodus neu einzuhängen, wenn das Recht CAP_SYS_ADMIN vorhanden ist oder durch die Erstellung eines verschachtelten Containers mit einem separaten Benutzer-Namespace mittels des Systemaufrufs unshare, in dem die Rechte CAP_SYS_ADMIN für den erstellten Container verfügbar sind.
Ein Angriff kann erfolgen, wenn Root-Rechte in einem isolierten Container vorhanden sind oder wenn ein Container ohne das Flag no_new_privs gestartet wird, welches das Erlangen zusätzlicher Berechtigungen verbietet. Das System muss die Unterstützung für Benutzer-Namensräume aktiviert haben (standardmäßig in Ubuntu und Fedora aktiviert, jedoch 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 Unterstützung für Benutzer-Namensräume und Zugriff auf die Root-Hierarchie der Cgroup v1 nicht erforderlich.
Neben dem Verlassen des isolierten Containers ermöglicht die Schwachstelle auch Prozessen, die vom Benutzer root ohne 'capabilities' oder von jedem Benutzer mit den Rechten CAP_DAC_OVERRIDE gestartet wurden (für den Angriff ist Zugriff auf die Datei /sys/fs/cgroup/*/release_agent erforderlich, die root gehört), Zugriff auf alle systemweiten 'capabilities'.
Es wird festgestellt, dass die Schwachstelle nicht ausgenutzt werden kann, wenn Schutzmechanismen wie Seccomp, AppArmor oder SELinux zur zusätzlichen Isolation 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
