Details zu einer Schwachstelle (CVE-2022-0492) in der Implementierung des cgroups v1-Ressourcenbegrenzungsmechanismus im Linux-Kernel, die zum Entkommen isolierter Container verwendet werden kann, wurden offengelegt. Das Problem besteht seit Linux-Kernel 2.6.24 und wurde in den Kernel-Releases 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 und 4.9.301 behoben. Sie können die Veröffentlichungen von Paketaktualisierungen in Distributionen auf diesen Seiten verfolgen: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Die Sicherheitslücke ist auf einen Logikfehler im Datei-Handler „release_agent“ zurückzuführen, der keine ordnungsgemäßen Prüfungen durchführt, wenn der Handler mit vollständigen Rechten ausgeführt wird. Die Datei „release_agent“ wird verwendet, um das Programm zu definieren, das vom Kernel ausgeführt werden soll, wenn ein Prozess in einer Kontrollgruppe beendet wird. Dieses Programm läuft als Root und mit allen „Fähigkeiten“ im Root-Namespace. Es wurde angenommen, dass nur der Administrator Zugriff auf die Einstellung „release_agent“ hatte, aber in Wirklichkeit beschränkten sich die Prüfungen darauf, dem Root-Benutzer Zugriff zu gewähren, was nicht ausschloss, dass die Einstellung vom Container aus oder durch einen Root-Benutzer ohne Administratorrechte (CAP_SYS_ADMIN) geändert wurde ).
Früher wäre eine solche Funktion nicht als Schwachstelle wahrgenommen worden, aber die Situation hat sich mit dem Aufkommen von Benutzernamensräumen (Benutzernamensräumen) geändert, die es Ihnen ermöglichen, separate Root-Benutzer in Containern zu erstellen, die sich nicht mit dem Root-Benutzer des Benutzers überschneiden Hauptumgebung. Dementsprechend reicht es für einen Angriff aus, Ihren release_agent-Handler in einem Container zu verbinden, der über einen eigenen Root-Benutzer in einem separaten Benutzer-ID-Bereich verfügt, der nach Abschluss des Vorgangs mit allen Rechten der Hauptumgebung ausgeführt wird.
Standardmäßig wird cgroupfs in einem Container im schreibgeschützten Modus gemountet, aber es ist kein Problem, diese Pseudofs im Schreibmodus erneut zu mounten, wenn Sie über CAP_SYS_ADMIN-Rechte verfügen oder indem Sie einen verschachtelten Container mit einem separaten Benutzernamensraum mithilfe des Systemaufrufs „unshare“ erstellen Für den erstellten Container stehen CAP_SYS_ADMIN-Rechte zur Verfügung.
Der Angriff kann ausgeführt werden, wenn Sie über Root-Rechte in einem isolierten Container verfügen oder wenn Sie einen Container ohne das Flag no_new_privs ausführen, das den Erhalt zusätzlicher Privilegien verhindert. Auf dem System muss die Unterstützung für Benutzernamespaces aktiviert sein (standardmäßig in Ubuntu und Fedora aktiviert, in Debian und RHEL jedoch nicht aktiviert) und Zugriff auf die Root-Cgroup v1 haben (Docker führt beispielsweise Container in der Root-RDMA-Cgroup aus). Der Angriff ist auch möglich, wenn Sie über CAP_SYS_ADMIN-Berechtigungen verfügen. In diesem Fall sind keine Unterstützung für Benutzernamensräume und kein Zugriff auf die Stammhierarchie der cgroup v1 erforderlich.
Zusätzlich zum Entkommen aus einem isolierten Container ermöglicht die Schwachstelle auch Prozesse, die von einem Root-Benutzer ohne „Fähigkeiten“ oder einem beliebigen Benutzer mit CAP_DAC_OVERRIDE-Rechten gestartet werden (der Angriff erfordert Zugriff auf die Datei /sys/fs/cgroup/*/release_agent). im Besitz von root), um Zugriff auf alle systemischen „Fähigkeiten“ zu erhalten.
Es wird darauf hingewiesen, dass die Schwachstelle nicht ausgenutzt werden kann, wenn die Schutzmechanismen Seccomp, AppArmor oder SELinux zur zusätzlichen Isolierung von Containern verwendet werden, da Seccomp den Zugriff auf den Systemaufruf unshare() blockiert und AppArmor und SELinux das Mounten von cgroupfs im Schreibmodus nicht zulassen.
Source: opennet.ru