{"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\/novosti-interneta\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","title":{"rendered":"Eine Schwachstelle in cgroups v1, die das Verlassen eines isolierten Containers erm\u00f6glicht.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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\u00fcgbar: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux. <\/p>\n
Die Sicherheitsanf\u00e4lligkeit resultiert aus einem logischen Fehler im Handler f\u00fcr die Datei release_agent, wodurch die erforderlichen \u00dcberpr\u00fcfungen bei der Ausf\u00fchrung des Handlers mit vollst\u00e4ndigen Rechten nicht durchgef\u00fchrt wurden. Die Datei release_agent wird verwendet, um das Programm zu bestimmen, das vom Kernel beim Abschluss eines Prozesses in einer cgroup ausgef\u00fchrt wird. Dieses Programm wird mit Root-Rechten und allen \u201eCapabilities\u201c im Root-Namensraum gestartet. Es wurde angenommen, dass nur Administratoren Zugriff auf die Konfiguration des release_agent haben, aber in der Praxis beschr\u00e4nkten sich die \u00dcberpr\u00fcfungen auf die Gew\u00e4hrung des Zugriffs f\u00fcr den Root-Benutzer, was nicht ausschloss, dass die Konfiguration aus einem Container oder von einem Root-Benutzer ohne Administratorrechte (CAP_SYS_ADMIN) ge\u00e4ndert werden konnte. <\/p>\n
Fr\u00fcher wurde eine solche Eigenschaft nicht als Sicherheitsanf\u00e4lligkeit angesehen, aber die Situation hat sich mit der Einf\u00fchrung der Benutzer-Namespace f\u00fcr Identifikatoren ge\u00e4ndert. Diese erm\u00f6glichen 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\u00fchrt wird. <\/p>\n
Standardm\u00e4\u00dfig wird cgroupfs im Container im Nur-Lese-Modus eingebunden, aber es gibt keine Probleme, dieses Pseudodateisystem im Schreibmodus neu einzuh\u00e4ngen, 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\u00fcr den erstellten Container verf\u00fcgbar sind.
<\/center> <\/p>\n
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\u00e4tzlicher Berechtigungen verbietet. Das System muss die Unterst\u00fctzung f\u00fcr Benutzer-Namensr\u00e4ume aktiviert haben (standardm\u00e4\u00dfig 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\u00f6glich, wenn die Privilegien CAP_SYS_ADMIN vorhanden sind; in diesem Fall sind Unterst\u00fctzung f\u00fcr Benutzer-Namensr\u00e4ume und Zugriff auf die Root-Hierarchie der Cgroup v1 nicht erforderlich. <\/p>\n
Neben dem Verlassen eines isolierten Containers erm\u00f6glicht die Sicherheitsanf\u00e4lligkeit auch Prozessen, die von einem Root-Benutzer ohne \u201eCapabilities\u201c oder von jedem Benutzer mit den Rechten CAP_DAC_OVERRIDE ausgef\u00fchrt werden (f\u00fcr den Angriff ist der Zugriff auf die Datei \/sys\/fs\/cgroup\/*\/release_agent erforderlich, die Root geh\u00f6rt), auf alle systemweiten \u201eCapabilities\u201c zuzugreifen. <\/p>\n
Es wird festgestellt, dass die Schwachstelle nicht ausgenutzt werden kann, wenn Schutzmechanismen wie Seccomp, AppArmor oder SELinux zur zus\u00e4tzlichen Isolation 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