Few days ago the news was released details have been revealed a vulnerability that was found in the implementation of the mechanism resource limitation cgroup v1 in the Linux kernel which is already cataloged under CVE-2022-0492.
This vulnerability found se can be used to exit isolated containers and it is detailed that the problem has been present since Linux kernel 2.6.24.
In the blog post it is mentioned that the vulnerability is due to a logical error in the release_agent file handler, so the proper checks were not performed when the driver was run with full permissions.
The file release_agent is used to define the program that the kernel executes when a process ends in a cgroup. This program runs as root with all "capability" in the root namespace. Only the administrator was supposed to have access to the release_agent configuration, but in reality, the checks were limited to granting access to the root user, which did not preclude changing the configuration from the container or by the non-administrative root user (CAP_SYS_ADMIN ).
Previously, this feature would not have been perceived as a vulnerability, but the situation has changed with the advent of user identifier namespaces (user namespaces), which allow you to create separate root users in containers that don't overlap with the root user of the main environment.
In consecuense, for an attack, it is enough in a container that has its own root user in a separate user id space to plug in your release_agent handler, which, once the process completes, will run with all the privileges of the parent environment.
By default, cgroupfs is mounted in a read-only container, but there is no problem remounting this pseudofs in write mode with CAP_SYS_ADMIN rights or by creating a nested container with a separate user namespace using the system call for stop sharing, in which CAP_SYS_ADMIN rights are available to the created container.
El ataque can be done by having root privileges in an isolated container or by running the container without the no_new_privs flag, which prohibits gaining additional privileges.
The system must have support for namespaces enabled user (enabled by default on Ubuntu and Fedora, but not enabled on Debian and RHEL) and have access to the root v1 cgroup (for example, Docker runs containers in the RDMA root cgroup). The attack is also possible with CAP_SYS_ADMIN privileges, in which case support for user namespaces and access to the root hierarchy of cgroup v1 is not required.
In addition to breaking out of the isolated container, the vulnerability also allows processes started by the root user without "capability" or any user with CAP_DAC_OVERRIDE rights (the attack requires access to the /sys/fs/cgroup/*/release_agent file owned by root) to obtain access to all the "capabilities" of the system.
Aside from containers, the vulnerability may also allow root host processes without capabilities, or non-root host processes with the CAP_DAC_OVERRIDE capability, to escalate privileges to full capabilities. This may allow attackers to bypass a hardening measure used by certain services, which remove capabilities in an attempt to limit the impact if a compromise occurs.
Unit 42 recommends users upgrade to a fixed kernel version. For those running containers, enable Seccomp and make sure AppArmor or SELinux is enabled. Prisma Cloud users can refer to the “Prisma Cloud Protections” section to see the mitigations provided by Prisma Cloud.
Note that the vulnerability cannot be exploited when using Seccomp, AppArmor or SELinux protection mechanisms for additional container isolation, as Seccomp blocks the unshare() system call and AppArmor and SELinux do not allow cgroupfs to be mounted in write mode.
Finally, it is worth mentioning that it was fixed in kernel versions 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 and 4.9.301. You can follow the release of package updates in distributions on these pages: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
Finally if you are interested in knowing more about it, you can check the details in the following link