Desde Linux Darkcrizt  

Encontraron una vulnerabilidad en cgroups v1 que permite salir de un contenedor aislado

Hace pocos dias se dio a conocer la noticia de que se han revelado los detalles de una vulnerabilidad que fue encontrada en la implementación del mecanismo de limitación de recursos cgroups v1 en el kernel de Linux la cual ya está catalogada bajo CVE-2022-0492.

Esta vulnerabilidad encontrada se puede utilizar para salir de contenedores aislados y se detalla que el problema ha estado presente desde el kernel de Linux 2.6.24.

En la publicación de blog se menciona que la vulnerabilidad se debe a un error lógico en el controlador de archivos release_agent, por lo que no se realizaron las comprobaciones adecuadas cuando el controlador se ejecutó con todos los permisos.

El archivo release_agent se utiliza para definir el programa que ejecuta el kernel cuando finaliza un proceso en un cgroup. Este programa se ejecuta como raíz con todas las «capacidades» en el espacio de nombres raíz. Se suponía que solo el administrador tenía acceso a la configuración de release_agent, pero en realidad, las comprobaciones se limitaban a otorgar acceso al usuario raíz, lo que no excluía cambiar la configuración desde el contenedor o por el usuario raíz no administrativo (CAP_SYS_ADMIN ).

Anteriormente, esta característica no se habría percibido como una vulnerabilidad, pero la situación ha cambiado con la llegada de los espacios de nombres de identificadores de usuario (espacios de nombres de usuario), que permiten crear usuarios root separados en contenedores que no se superponen con el usuario raíz del entorno principal.

En consecuencia, para un ataque, es suficiente en un contenedor que tiene su propio usuario root en un espacio de identificación de usuario separado para conectar su controlador release_agent, que, una vez que se completa el proceso, se ejecutará con todos los privilegios del entorno principal.

De forma predeterminada, cgroupfs se monta en un contenedor de solo lectura, pero no hay problema para volver a montar este pseudofs en modo de escritura con derechos CAP_SYS_ADMIN o creando un contenedor anidado con un espacio de nombres de usuario separado usando la llamada al sistema para dejar de compartir, en el que los derechos CAP_SYS_ADMIN están disponibles para el contenedor creado.

El ataque se puede llevar a cabo teniendo privilegios de root en un contenedor aislado o ejecutando el contenedor sin el indicador no_new_privs, que prohíbe obtener privilegios adicionales.

El sistema debe tener habilitado el soporte para los espacios de nombres de usuario (habilitado de forma predeterminada en Ubuntu y Fedora, pero no habilitado en Debian y RHEL) y tener acceso al cgroup root v1 (por ejemplo, Docker ejecuta contenedores en el cgroup raíz RDMA). El ataque también es posible con los privilegios CAP_SYS_ADMIN, en cuyo caso no se requiere soporte para espacios de nombres de usuario ni acceso a la jerarquía raíz de cgroup v1.

Además de salir del contenedor aislado, la vulnerabilidad también permite procesos iniciados por el usuario root sin «capacidades» o cualquier usuario con derechos CAP_DAC_OVERRIDE (el ataque requiere acceso al archivo /sys/fs/cgroup/*/release_agent propiedad del root) para obtener acceso a todas las «capacidades» del sistema.

Aparte de los contenedores, la vulnerabilidad también puede permitir que los procesos de host raíz sin capacidades, o los procesos de host no raíz con la capacidad CAP_DAC_OVERRIDE , aumenten los privilegios y alcancen todas las capacidades. Esto puede permitir a los atacantes eludir una medida de endurecimiento utilizada por ciertos servicios, que eliminan capacidades en un intento de limitar el impacto si ocurre un compromiso.

Unit 42 recomienda a los usuarios actualizar a una versión de kernel fija. Para aquellos que ejecutan contenedores, habilite Seccomp y asegúrese de que AppArmor o SELinux estén habilitados. Los usuarios de Prisma Cloud pueden consultar la sección «Protecciones de Prisma Cloud» para ver las mitigaciones proporcionadas por Prisma Cloud.

Se advierte que la vulnerabilidad no puede ser explotada al utilizar mecanismos de protección Seccomp, AppArmor o SELinux para aislamiento adicional de contenedores, ya que Seccomp bloquea la llamada al sistema unshare() y AppArmor y SELinux no permiten montar cgroupfs en modo escritura.

Por último cabe mencionar que se solucionó en las versiones del kernel 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 y 4.9.301. Puede seguir la publicación de actualizaciones de paquetes en distribuciones en estas páginas: DebianSUSEUbuntuRHELFedoraGentooArch Linux.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

Leave A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.