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.
The vulnerability is caused by a logic error in the release_agent file handler, which led to insufficient checks when launching the handler with full privileges. The release_agent file is used to determine the program executed by the kernel upon process termination in a cgroup. This program runs with root privileges and with all capabilities in the root namespace. It was assumed that only an administrator would have access to configure the release_agent, but in reality, checks were limited to providing access to the root user, which did not preclude modification of the configuration from inside the container or by the root user without administrator rights (CAP_SYS_ADMIN).
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.
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.
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.
In addition to exiting the isolated container, the vulnerability also allows processes run by the root user without ‘capabilities’ or any user with CAP_DAC_OVERRIDE rights (access to the file /sys/fs/cgroup/*/release_agent, owned by root, is required for the attack) to access all system ‘capabilities.’
It is noted that the vulnerability cannot be exploited when using Seccomp, AppArmor, or SELinux protection mechanisms for additional container isolation, as Seccomp blocks access to the unshare() system call, and AppArmor and SELinux do not allow mounting cgroupfs in write mode.
Source: opennet.ru
