Kwetsbaarheid in cgroups v1, waardoor het mogelijk is om uit een geïsoleerde container te ontsnappen

Details of the vulnerability (CVE-2022-0492) in the implementation of the resource limitation mechanism cgroups v1 in the Linux kernel have been revealed, which can be used to escape isolated containers. The issue manifests itself starting from 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. One can track the publication 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 prevented the necessary checks from being performed 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 the cgroup. This program runs with root privileges and with all 'capabilities' in the root namespace. It was intended that only the administrator could access the configuration of release_agent, but in reality, the checks were limited to granting access to the root user, which did not preclude modification of the settings from within a container or by the root user without admin 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 ID namespaces, which allow the creation of separate root users in containers that do not overlap with the root user of the main environment. Consequently, to launch an attack, it is sufficient to connect one’s own release_agent handler in a container that has its own root user in a separate user ID namespace, which will then be executed with full privileges of the main environment after the process concludes.

By default, cgroupfs is mounted in the container in read-only mode, but there is no problem remounting this pseudo-fs in write mode if one has CAP_SYS_ADMIN rights or by creating an inner container with a separate user namespace using the unshare syscall, in which the CAP_SYS_ADMIN rights are accessible for the created container.

Een aanval kan worden uitgevoerd met root-rechten in een geïsoleerde container of wanneer de container wordt uitgevoerd zonder de no_new_privs-vlag die het verkrijgen van aanvullende privileges verbiedt. De ondersteuning voor user namespaces moet in het systeem zijn ingeschakeld (standaard ingeschakeld in Ubuntu en Fedora, maar niet geactiveerd in Debian en RHEL) en er moet toegang zijn tot de root cgroup v1 (bijvoorbeeld Docker draait containers in de root RDMA cgroup). Een aanval is ook mogelijk met CAP_SYS_ADMIN-rechten, waarbij ondersteuning voor user namespaces en toegang tot de root cgroup v1-hiërarchie niet vereist zijn.

Naast het ontsnappen uit de geïsoleerde container, stelt de kwetsbaarheid processen die door de root-gebruiker zonder 'capabilities' zijn gestart of door elke gebruiker met CAP_DAC_OVERRIDE-rechten in staat om toegang te krijgen tot alle systeem 'capabilities' (voor de aanval is toegang tot het bestand /sys/fs/cgroup/*/release_agent, dat toebehoort aan root, vereist).

Het is te merken dat de kwetsbaarheid niet kan worden geëxploiteerd wanneer de beschermingsmechanismen Seccomp, AppArmor of SELinux worden toegepast voor extra isolatie van containers, omdat Seccomp de systeemaanroep unshare() blokkeert en AppArmor en SELinux niet toestaan dat cgroupfs in schrijfmodus wordt gemonteerd.

Bron: opennet.ru