Se han revelado detalles sobre la vulnerabilidad (CVE-2022-0492) en la implementación del mecanismo de restricción de recursos cgroups v1 en el núcleo de Linux, que puede ser utilizada para escapar de contenedores aislados. El problema se presenta a partir del núcleo de Linux 2.6.24 y ha sido corregido en las versiones del núcleo 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 y 4.9.301. Se puede seguir la publicación de las actualizaciones de los paquetes en las distribuciones en estas páginas: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.
La vulnerabilidad es causada por un error lógico en el manejador de archivos release_agent, lo que impide que se realicen las verificaciones adecuadas al iniciar el manejador con un conjunto completo de privilegios. El archivo release_agent se utiliza para determinar el programa que ejecuta el núcleo al finalizar un proceso en cgroup. Este programa se ejecuta con derechos de root y con todas las «capabilities» en el espacio de nombres raíz. Se suponía que solo el administrador tenía acceso para configurar release_agent, pero en realidad las verificaciones se limitaban a otorgar acceso al usuario root, lo que no excluía la modificación de la configuración desde un contenedor o por un usuario root sin derechos de administrador (CAP_SYS_ADMIN).
Antes, esta característica no se habría considerado una vulnerabilidad, pero la situación ha cambiado con la aparición de espacios de nombres de identificadores de usuario (user namespaces), que permiten crear en contenedores usuarios root separados que no se cruzan con el usuario root del entorno principal. Por lo tanto, para llevar a cabo un ataque, solo es necesario en un contenedor que tiene su propio usuario root en un espacio de identificadores de usuario separado, conectar su propio manejador release_agent, que después de finalizar el proceso se ejecutará con plenos privilegios en el entorno principal.
Por defecto, cgroupfs se monta en el contenedor en modo de solo lectura, pero no hay problemas en volver a montar este pseudofs en modo de escritura si se tienen privilegios CAP_SYS_ADMIN o mediante la creación usando la llamada al sistema unshare de un contenedor anidado con un espacio de nombres de usuario separado, en el cual los derechos CAP_SYS_ADMIN están disponibles para el contenedor creado.
Un ataque puede llevarse a cabo con privilegios de root en un contenedor aislado o al ejecutar un contenedor sin la opción no_new_privs, que prohíbe obtener privilegios adicionales. El sistema debe tener habilitado el soporte para espacios de nombres de usuario (que está habilitado de forma predeterminada en Ubuntu y Fedora, pero no está activado en Debian y RHEL) y debe haber acceso al cgroup v1 raíz (por ejemplo, Docker ejecuta contenedores en el cgroup RDMA raíz). El ataque también es posible con privilegios CAP_SYS_ADMIN, en cuyo caso no se requiere el soporte de espacios de nombres de usuario ni acceso a la jerarquía cgroup v1 raíz.
Además de la salida del contenedor aislado, la vulnerabilidad también permite que los procesos ejecutados por el usuario root sin 'capabilities' o cualquier usuario con derechos CAP_DAC_OVERRIDE (para el ataque se requiere acceso al archivo /sys/fs/cgroup/*/release_agent, que pertenece a root) accedan a todas las 'capabilities' del sistema.
Se señala que la vulnerabilidad no puede ser explotada si se aplican mecanismos de protección Seccomp, AppArmor o SELinux para una mayor aislamiento de los contenedores, ya que Seccomp bloquea la llamada al sistema unshare(), mientras que AppArmor y SELinux no permiten montar cgroupfs en modo de escritura.
Fuente: opennet.ru
