{"id":103483,"date":"2022-03-06T15:36:45","date_gmt":"2022-03-06T13:36:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera"},"modified":"2022-03-06T15:36:45","modified_gmt":"2022-03-06T13:36:47","slug":"uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","title":{"rendered":"Eine Schwachstelle in cgroups v1, die es erm\u00f6glicht, aus einem isolierten Container auszubrechen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Details der Schwachstelle (CVE-2022-0492) in der Implementierung des Ressourcenbeschr\u00e4nkungsmechanismus 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\u00f6ffentlichung von Updates f\u00fcr Pakete in den Distributionen kann auf den folgenden Seiten verfolgt werden: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux. <\/p>\n
Die Vulnerabilit\u00e4t wird durch einen Logikfehler im Handler f\u00fcr die Datei release_agent verursacht, wodurch die erforderlichen \u00dcberpr\u00fcfungen beim Starten des Handlers mit vollst\u00e4ndigen Berechtigungen nicht durchgef\u00fchrt wurden. Die Datei release_agent wird verwendet, um das Programm zu bestimmen, das vom Kernel beim Beenden eines Prozesses in der cgroup ausgef\u00fchrt wird. Programmiert wird dieses mit den Rechten von root und allen \u201ecapabilities\u201c im Root-Namespace. Es war vorgesehen, dass nur der Administrator Zugang zu den Einstellungen f\u00fcr release_agent hat, doch tats\u00e4chlich beschr\u00e4nkten sich die Pr\u00fcfungen auf die Gew\u00e4hrung von Zugang zum Nutzer root, was eine \u00c4nderung der Einstellung aus einem Container oder durch den Nutzer root ohne Administratorrechte (CAP_SYS_ADMIN) nicht ausschloss. <\/p>\n
Fr\u00fcher w\u00e4re eine solche Eigenschaft nicht als Schwachstelle wahrgenommen worden, aber die Situation hat sich mit dem Aufkommen von Benutzer-Namensr\u00e4umen (user namespaces) ge\u00e4ndert, 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\u00e4tsraum seinen eigenen release_agent-Handler anzuschlie\u00dfen, der nach dem Beenden des Prozesses mit vollen Rechten der Hauptumgebung ausgef\u00fchrt wird. <\/p>\n
Standardm\u00e4\u00dfig 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 \u00fcber den Systemaufruf unshare im Schreibmodus zu remounten, wobei f\u00fcr den erstellten Container die Rechte CAP_SYS_ADMIN verf\u00fcgbar sind.
<\/center> <\/p>\n
Ein Angriff kann durchgef\u00fchrt werden, wenn Root-Rechte in einem isolierten Container vorhanden sind oder wenn der Container ohne das Flag no_new_privs, das den Erhalt zus\u00e4tzlicher Privilegien verbietet, gestartet wird. Das System muss die Unterst\u00fctzung von Benutzer-Namensr\u00e4umen aktiviert haben (standardm\u00e4\u00dfig 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\u00f6glich, wenn die Privilegien CAP_SYS_ADMIN vorhanden sind; in diesem Fall sind die Unterst\u00fctzung von Benutzer-Namensr\u00e4umen und der Zugriff auf die Root-Hierarchie der Cgroup v1 nicht erforderlich. <\/p>\n
Neben dem Verlassen eines isolierten Containers erm\u00f6glicht die Vulnerabilit\u00e4t auch Prozessen, die von einem Nutzer root ohne \u201ecapabilities\u201c oder jedem Nutzer mit den Rechten CAP_DAC_OVERRIDE gestartet werden (f\u00fcr den Angriff ist Zugang zur Datei \/sys\/fs\/cgroup\/*\/release_agent erforderlich, die root geh\u00f6rt), Zugriff auf alle systemweiten \u201ecapabilities\u201c. <\/p>\n
Es wird festgestellt, dass die Sicherheitsanf\u00e4lligkeit nicht ausgenutzt werden kann, wenn Mechanismen wie Seccomp, AppArmor oder SELinux zum zus\u00e4tzlichen Isolieren von Containern verwendet werden, da Seccomp den Zugriff auf den Systemaufruf unshare() blockiert, w\u00e4hrend AppArmor und SELinux das Einh\u00e4ngen von cgroupfs im Schreibmodus verhindern. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Eine](\"\/wp-content\/uploads\/2022\/03\/710b37582c444cc4be7d6ae4695c8afe.jpg\")
<\/center> <\/p>\n