Hace pocos dias se dio a conocer la noticia de que se identificó la vulnerabilidad (ya catalogada bajo CVE-2022-0185) en la API de contexto del sistema de archivos proporcionada por el kernel de Linux que podría permitir que un usuario local obtenga privilegios de root en el sistema.
Se menciona que el problema es que un usuario sin privilegios puede obtener dichos permisos en un contenedor aislado si el soporte para espacios de nombres de usuario está habilitado en el sistema.
Por ejemplo, los espacios de nombres de usuario están habilitados de manera predeterminada en Ubuntu y Fedora, pero no están habilitados en Debian y RHEL (a menos que se usen plataformas de aislamiento de contenedores). Además de la escalada de privilegios, la vulnerabilidad también se puede utilizar para salir de un contenedor aislado si el contenedor tiene la autorización CAP_SYS_ADMIN.
La vulnerabilidad existe en la función legacy_parse_param() en VFS y se debe a la falta de una validación adecuada del tamaño máximo de los parámetros proporcionados en los sistemas de archivos que no son compatibles con la API de contexto del sistema de archivos.
Recientemente, varios amigos de mi equipo CTF Crusaders of Rust y yo encontramos un desbordamiento del montón del kernel de Linux 0-day. Encontramos el error a través de fuzzing con syzkaller y rápidamente lo desarrollamos en un exploit LPE de Ubuntu. Luego, lo reescribimos para escapar y rootear la infraestructura reforzada de CTF de Kubernetes de Google. Este error afecta a todas las versiones del kernel desde la 5.1 (la 5.16 está actualmente en curso) y se le ha asignado CVE-2022-0185. Ya hemos informado esto a la lista de correo de seguridad y distribución de Linux, y el error se corrigió a partir del lanzamiento de este artículo
Al pasar un parámetro demasiado grande, puede provocar un desbordamiento de la variable entera utilizada para calcular el tamaño de los datos que se escriben; el código tiene una verificación de desbordamiento de búfer «if (len > PAGE_SIZE – 2 – size)», que no funciona si el valor de tamaño es mayor que 4094 debido al desbordamiento de enteros a través del límite inferior (desbordamiento de enteros, cuando convierte 4096 – 2 – 4095 a int sin firmar, obtiene 2147483648).
Este error permite, al acceder a una imagen FS especialmente diseñada, provocar un desbordamiento del búfer y sobrescribir los datos del kernel que siguen al área de memoria asignada. Para explotar la vulnerabilidad, se requieren derechos CAP_SYS_ADMIN, es decir, autoridad del administrador.
A partir de 2022, nuestros compañeros de equipo se resolvieron a encontrar un día 0 en 2022. No estábamos muy seguros de cómo comenzar exactamente, pero dado que nuestro equipo tenía un alto grado de familiaridad con las vulnerabilidades del kernel de Linux, decidimos simplemente comprar algunos servidores dedicados. y ejecuta el fuzzer syzkaller de Google. El 6 de enero a las 22:30 PST, chop0 recibió el siguiente informe sobre una falla de KASAN en legacy_parse_param: slab-out-of-bounds Write in legacy_parse_param. Parece que syzbot encontró este problema solo 6 días antes cuando fuzzing Android, pero el problema no se manejó y pensamos ingenuamente que nadie más se dio cuenta.
Finalmente, cabe mencionar que el problema se ha estado manifestando desde la versión del kernel de Linux 5.1 y se solucionó en las actualizaciones que fueron lanzadas hace pocos dias en las versiones 5.16.2, 5.15.16, 5.10.93, 5.4.173.
Ademas de que ya se han publicado actualizaciones de paquetes de vulnerabilidades para RHEL, Debian, Fedora y Ubuntu. Mientras que la solución aún no está disponible en Arch Linux, Gentoo, SUSE y openSUSE.
Para el caso de estas se menciona que como solución de seguridad para los sistemas que no utilizan el aislamiento de contenedores, puede establecer el valor de sysctl «user.max_user_namespaces» en 0:
El investigador que identificó el problema ha publicado una demostración de un exploit que permite ejecutar el código como root en Ubuntu 20.04 en la configuración predeterminada. Está previsto que el código de explotación se publique en GitHub dentro de una semana después de que las distribuciones publiquen una actualización que solucione la vulnerabilidad.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Otra razón más para no tocar snap ni con un palo.