{"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\/en\/blog\/news\/uyazvimost-v-cgroups-v1-pozvolyayushhaya-vyjti-iz-izolirovannogo-kontejnera","title":{"rendered":"A vulnerability in cgroups v1 allows escaping from an isolated container","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Details of the vulnerability (CVE-2022-0492) in the implementation of the resource limitation mechanism for cgroups v1 in the Linux kernel have been revealed, which can be exploited to escape from isolated containers. The issue manifests starting from the Linux kernel 2.6.24 and has been fixed in kernel releases 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266, and 4.9.301. You can track the announcements of package updates in distributions on these pages: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux. <\/p>\n
The vulnerability is caused by a logical error in the release_agent file handler, which prevents proper checks from being executed when the handler runs with full privileges. The release_agent file is used to determine the program executed by the kernel upon the termination of a process in a cgroup. This program runs with root privileges and all capabilities in the root namespace. It was intended that only administrators have access to the release_agent configuration, but in practice, checks were limited to granting access to the root user, which did not preclude modification of the configuration from within a container or by a root user without administrator rights (CAP_SYS_ADMIN). <\/p>\n
Previously, such a feature would not have been perceived as a vulnerability, but the situation changed with the emergence of user namespaces, which allow the creation of separate root users within containers, independent from the root user of the host environment. Consequently, to exploit this, it is sufficient to connect a custom release_agent handler in a container that has its own root user in a separate user ID namespace, which will then execute with full privileges of the host environment upon process termination. <\/p>\n
By default, cgroupfs is mounted in containers in read-only mode, but there are no issues remounting this pseudo-filesystem in write mode if CAP_SYS_ADMIN rights are present or through the creation of an inner container with a separate user namespace using the unshare system call, where the created container has access to CAP_SYS_ADMIN rights.
<\/center> <\/p>\n
An attack can be carried out with root privileges in an isolated container or when running a container without the no_new_privs flag, which prevents gaining additional privileges. User namespaces support must be enabled in the system (enabled by default in Ubuntu and Fedora, but not activated in Debian and RHEL), and access to the root cgroup v1 must be present (for example, Docker runs containers in the root RDMA cgroup). An attack is also possible with CAP_SYS_ADMIN privileges; in this case, user namespaces support and access to the root cgroup v1 hierarchy are not required. <\/p>\n
In addition to escaping an isolated container, the vulnerability also allows processes launched by the root user without capabilities or any user with CAP_DAC_OVERRIDE rights (access to the file \/sys\/fs\/cgroup\/*\/release_agent, which belongs to root is required for the attack) to gain access to all system capabilities. <\/p>\n
![\"A](\"\/wp-content\/uploads\/2022\/03\/710b37582c444cc4be7d6ae4695c8afe.jpg\")
<\/center> <\/p>\n