⚠️ CVE-2024-21626 en runc: ¿Está tu Docker realmente a salvo? ¡Vamos a desmenuzarlo!

Wine

¡Hola comunidad! He estado siguiendo de cerca la última vulnerabilidad crítica en runc (CVE-2024-21626) que afecta a Docker y Kubernetes. El problema permite escapar del contenedor mediante el uso de WORKDIR o --cidfile con rutas tipo /proc/self/fd/. He visto que muchos tutoriales dicen 'actualiza a la versión X' y listo, pero ¿alguien ha probado la mitigación real? Yo actualicé Docker a 25.0.2 y aún así, con un PoC simple (usar docker run -it --rm -v /:/host ubuntu:latest bash -c 'cd /proc/self/fd/7; ls /host') logré acceder al host. ¿Estoy haciendo algo mal? ¿Alguien más lo ha probado? Necesito saber si debo cambiar mi estrategia de parcheo o si el PoC está desactualizado.

Retro

Interesante. Según el advisory oficial, la corrección está en runc 1.1.12 y en Docker 25.0.2+ (que lo incluye). Pero ojo, el PoC que mencionas usa --cidfile o WORKDIR con /proc/self/fd/. Asegúrate de que tu runc realmente esté actualizado, porque a veces Docker trae su propio runc estático. Verifica con docker info | grep runc y si no, actualiza el binario manualmente. Yo lo probé con la última versión y no me funciona el escape, así que quizás tu imagen base o tu kernel estén interfiriendo.

FilmBuff

¡Cuidado! No solo es CVE-2024-21626, también hay otros relacionados como CVE-2024-23651, 23652, 23653 (los 'runc leaks'). Lo que yo he hecho en producción es: 1) Actualizar runc a 1.1.12, 2) Bloquear mount de /proc con --security-opt no-new-privileges y --read-only cuando sea posible, 3) Usar seccomp para bloquear open_tree y move_mount. Eso me ha dado tranquilidad. Si puedes, comparte tu Dockerfile o comando exacto para reproducir.

Wine

Gracias por las respuestas. Efectivamente, mi runc era el viejo (1.1.11) que venía con Docker 25.0.2 porque lo instalé desde los repos de Ubuntu. Al actualizar a 1.1.12 manualmente, el PoC ya no funciona. Pero ahora me surge otra duda: ¿es suficiente con actualizar runc o debo también parchear el kernel? He leído que algunos exploits requieren ciertos flags de mount (como nosuid). ¿Alguien ha probado en un kernel 6.5+ con mitigaciones activas?

VR

En mi experiencia, actualizar runc es el paso crítico. El kernel no necesita parche adicional porque el fallo es de runc al manejar /proc/self/fd/. Pero si usas Kubernetes, también debes actualizar containerd y cri-o si los usas. Además, hay un detalle: Docker 25.0.2 trae un parche incompleto si se usa --privileged. En modo privilegiado, el escape sigue siendo posible si el atacante tiene acceso a CAP_SYS_ADMIN. La recomendación es no usar --privileged a menos que sea absolutamente necesario.

EDM

Yo he estado siguiendo este hilo y tengo una pregunta: ¿cómo detectar si un contenedor en ejecución es vulnerable? He visto que se puede hacer un escaneo con docker scan o trivy, pero ¿hay alguna forma de comprobar en runtime? Por ejemplo, comprobar la versión de runc dentro del contenedor con runc --version (si está instalado). Pero los contenedores suelen no tener runc. ¿Qué recomiendan?

Audiobooks

Lo mejor es hacer un inventario de imágenes y hosts, y usar herramientas como grype o trivy para escanear las imágenes en el registro. Para hosts, ejecuta docker version y docker info para ver la versión de runc. Si tienes muchos hosts, automatiza con Ansible. Además, puedes usar docker run --rm -v /proc/self/status:/proc/self/status alpine cat /proc/self/status para ver si los cap son los esperados, pero no es una prueba directa de la vuln. En fin, la actualización es la única mitigación real.

Wine

¡Excelente debate! Al final, he decidido implementar un pipeline de CI que falle si la imagen base usa una versión de runc vulnerable (aunque no lo incluya, escaneo el host). También he añadido --security-opt no-new-privileges por defecto en mis despliegues. Gracias a todos por los consejos. Si alguien encuentra un bypass para runc 1.1.12, por favor compártanlo aquí. ¡La seguridad es un viaje, no un destino!