Hace pocos días se dio a conocer información sobre una nueva vulnerabilidad crítica que fue descubierta en la utilidad Sudo (la herramienta de administración de privilegios más utilizada en Linux).
Catalogada como CVE-2025-32463, esta falla permite a cualquier usuario local sin privilegios ejecutar comandos con acceso root, incluso si no está listado en la configuración de sudoers. El fallo ha sido verificado en distribuciones populares como Ubuntu 24.04 y Fedora 41, afectando su configuración predeterminada.
El origen del problema está en la opción –chroot (-R) de Sudo, que permite ejecutar comandos en un entorno de sistema de archivos aislado. Al utilizar esta opción, Sudo cambia el directorio root al indicado por el usuario. Lo peligroso es que, en este proceso, Sudo carga el archivo /etc/nsswitch.conf del entorno chroot, no el del sistema original.
Esto abre la puerta a un ataque ingenioso: si el usuario crea un entorno chroot propio e incluye en él un archivo nsswitch.conf manipulado, puede forzar al sistema a cargar bibliotecas compartidas personalizadas ubicadas dentro de ese entorno. Como el subsistema NSS (Name Service Switch) ejecuta código antes de abandonar los privilegios de root, el atacante logra que su código malicioso se ejecute con privilegios de superusuario.
CVE-2025-32463: Prueba de concepto y detalles técnicos
La explotación de esta vulnerabilidad ha sido demostrada con un exploit en Bash que utiliza una biblioteca compartida personalizada y un archivo de configuracion modificado. Al ejecutar sudo -R woot woot sobre este entorno, el sistema carga la biblioteca bajo privilegios root, lo que da como resultado una escalada directa de privilegios.
Aunque chroot se emplea comúnmente para limitar el acceso al sistema de archivos, como ocurre en servidores FTP o SFTP, no fue diseñada como una medida de seguridad. De hecho, el propio manual de Linux lo advierte: chroot() solo cambia el directorio raíz del proceso, pero no impide llamadas peligrosas ni proporciona aislamiento real.
En Sudo, la opción -R cambia el root antes de ejecutar el comando, lo cual puede ser útil en escenarios específicos, pero también extremadamente riesgoso si se permite a usuarios sin privilegios definir el entorno.
Este ataque ha sido verificado en versiones de Sudo desde la 1.9.14 hasta la 1.9.17, aunque se sospecha que podría afectar desde la versión 1.8.33. No obstante, las versiones antiguas (≤ 1.8.32) no son vulnerables porque no implementan la función chroot.
Otra vulnerabilidad relacionada: CVE-2025-32462
La actualización que corrige este problema también soluciona una segunda vulnerabilidad, identificada como CVE-2025-32462, que permite eludir restricciones de host en sudoers.
Esta falla se presenta cuando el usuario utiliza la opción –host (-h) no solo para listar reglas de privilegios, sino también para ejecutar comandos, lo que no estaba previsto. Si el archivo de configuración incluye reglas como testuser testhost = ALL, un usuario podría ejecutar sudo -h testhost para ejecutar comandos root en cualquier host, burlando así las restricciones.
Sin embargo, esta segunda falla solo afecta a usuarios que ya están en sudoers y cuya configuración específica incluye restricciones de host.
¿Qué distribuciones están afectadas?
Se ha confirmado la vulnerabilidad en:
- Ubuntu 24.04.1 con Sudo 1.9.15p5 y 1.9.16p2
- Fedora 41 con Sudo 1.9.15p5
Las versiones vulnerables abarcan el rango 1.9.14 a 1.9.17, y es importante recalcar que la opción chroot está obsoleta desde Sudo 1.9.17p1. Por lo tanto, su uso ya no es recomendable en entornos de producción.
¿Qué se recomienda hacer?
El equipo de investigación de Stratascale ha recomendado las siguientes acciones:
- Actualizar Sudo a la versión 1.9.17p1 o superior.
- Evitar el uso de la opción chroot, dado que su funcionalidad ha quedado obsoleta por razones de seguridad.
- Verificar el uso de runchroot= o directivas similares en /etc/sudoers y en los archivos dentro de /etc/sudoers.d.
- Revisar los registros del sistema en busca de entradas de Sudo que utilicen CHROOT=.
- Usar herramientas como ldapsearch si las reglas de sudoers se almacenan en LDAP.
Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...