El parche no se guardó: un error crítico en NVIDIA Container Toolkit tuvo que corregirse dos veces

En septiembre de 2024, la empresa NVIDIA lanzó una actualización para corregir la vulnerabilidad crítica CVE-2024-0132 en su herramienta Container Toolkit. El problema residía en una condición de carrera del tipo TOCTOU (Time-of-Check to Time-of-Use), lo que permitía a los atacantes ejecutar un llamado "escape del contenedor" y acceder a los recursos del sistema anfitrión. La vulnerabilidad recibió una puntuación alta en la escala CVSS: 9.0. Sin embargo, como se descubrió más tarde, la protección resultó ser incompleta, y a principios de 2025 los expertos detectaron la posibilidad de su evasión.

El análisis realizado por especialistas de Trend Micro confirmó que la corrección de NVIDIA no elimina completamente la vulnerabilidad. Además, el estudio reveló otro problema relacionado con el rendimiento que afecta a Docker en Linux y que puede provocar una denegación de servicio. Esto hace que la situación sea potencialmente peligrosa no solo desde el punto de vista de la seguridad, sino también en términos de la estabilidad del funcionamiento de los servidores.

El descubrimiento de la nueva vulnerabilidad recibió el identificador CVE-2025-23359 y la misma puntuación alta de peligrosidad — 9.0 puntos. El núcleo del problema se encuentra en la función mount_files, responsable de montar los sistemas de archivos. Durante el análisis se detectó la ausencia de bloqueos, lo que permite modificar el objeto antes de que la operación se complete. Si un atacante ya tiene acceso a la ejecución de código dentro del contenedor, puede utilizar esta vulnerabilidad para escalar privilegios y ejecutar código arbitrario en nombre del sistema anfitrión.

Resulta interesante que ya en febrero de 2025 la empresa Wiz advirtió sobre la posibilidad de evasión de la vulnerabilidad original, pero solo ahora se han confirmado técnicamente estos datos. Ambos problemas fueron corregidos en la versión 1.17.4 del NVIDIA Container Toolkit, sin embargo, la eficacia de la actualización depende de la activación de ciertos parámetros — por ejemplo, "allow-cuda-compat-libs-from-container".

Además del riesgo de "escape del contenedor", los investigadores descubrieron una amenaza menos obvia — la fuga de recursos debido a la acumulación de entradas en la tabla de montaje de Linux. Cuando se crea un contenedor con varios puntos de montaje y se utiliza el parámetro "bind-propagation=shared", al eliminarlo las entradas permanecen en el sistema. Esto lleva a un crecimiento descontrolado de la tabla y al agotamiento de los descriptores de archivos. Como resultado, Docker se vuelve incapaz de lanzar nuevos contenedores y los usuarios no pueden conectarse al anfitrión ni siquiera a través de SSH.

Para reducir los riesgos, se propone implementar un monitoreo regular de la tabla de montaje, restringir el acceso a la API de Docker, usar un sistema de control de acceso estricto y realizar auditorías de volúmenes y conexiones entre los contenedores y el sistema anfitrión. Esto es especialmente relevante para infraestructuras que trabajan con bibliotecas CUDA en un entorno aislado.

El hecho de que existan dos problemas críticos — tanto en seguridad como en rendimiento — subraya la importancia de una protección multinivel al trabajar con contenedores. Incluso con actualizaciones oficiales, su corrección y exhaustividad deben verificarse mediante herramientas adicionales.