“Leaky Vessels” fue una de las historias de seguridad de contenedores más sonadas de 2024, y aunque la vulnerabilidad concreta lleva tiempo parcheada, sigue siendo el ejemplo de manual que conviene tener presente cada vez que pones un contenedor sobre Proxmox. El fallo principal, CVE-2024-21626, es un escape de contenedor en runc —el runtime de bajo nivel que Docker, containerd y Kubernetes usan por debajo para arrancar contenedores— con una puntuación CVSS 3.1 de 8.6 (Alta).
Lo traemos de vuelta no por nostalgia, sino porque la lección estructural no caduca: si hay un binario de runc en cualquier parte de tu infraestructura Proxmox, su higiene es responsabilidad tuya, y los hábitos que cerraron Leaky Vessels son los mismos que blindan contra el próximo CVE del runtime.
El fallo es una fuga de descriptor de fichero en runc. Bajo ciertas condiciones, un descriptor interno que apunta al sistema de ficheros del host quedaba abierto y era heredado por el proceso del contenedor. Con una imagen o configuración maliciosa —por ejemplo, abusando de la instrucción WORKDIR para resolver una ruta a través de ese descriptor filtrado—, un proceso dentro del contenedor acababa operando en el espacio de nombres de ficheros del host en lugar del suyo.
A partir de ahí, un atacante podía leer ficheros del host o, peor, sobrescribir binarios del host para lograr una fuga completa de contenedor a anfitrión. La explotación requiere interacción —construir o ejecutar una imagen maliciosa—, lo que se refleja en el vector CVSS, pero el impacto es compromiso total del host.
Muchos despliegues de Proxmox no se quedan en VMs y LXCs: también ejecutan cargas de Docker, normalmente en uno de dos patrones:
En ambos casos el motor de contenedores incluye runc, así que ambos estaban expuestos a CVE-2024-21626. El matiz importante: los contenedores nativos de Proxmox usan liblxc, no runc, de modo que un LXC sin Docker no se ve afectado directamente por este CVE en concreto. El riesgo aparece en el momento en que instalas Docker (u otro runtime OCI) en el host, en una VM o en un contenedor.
Esto es exactamente por qué importan las fronteras de confianza al anidar: una fuga de Docker dentro de un LXC te deja en el root de ese LXC, y un LXC privilegiado comparte mucho con el host Proxmox. Apilar contenedores sin pensar dónde está cada frontera es lo que convierte un fallo de runtime en un incidente de plataforma.
Apunte de actualidad: la función de imágenes OCI nativas que estrenó Proxmox VE 9.1 y sigue en la 9.2 ejecuta la imagen como contenedor LXC sin levantar el demonio Docker, así que no introduce un dockerd ni un runc por esa vía. No es una bala de plata —sigue siendo un contenedor con kernel compartido—, pero sí evita arrastrar el runtime de Docker solo para correr un servicio. Lo desarrollamos en el análisis de Docker/OCI en Proxmox VE 9.2.
Averigua en qué versión de runtime estás:
# Dentro de la VM/LXC (o el host) que ejecuta Docker
docker version
runc --versionSi runc está por debajo de 1.1.12, actualízalo. La corrección llegó precisamente en runc 1.1.12. En sistemas basados en Debian/Ubuntu eso significa tirar de los paquetes parcheados de Docker/containerd:
apt update
apt install --only-upgrade docker-ce docker-ce-cli containerd.io
# o, si runc viene empaquetado por separado:
apt install --only-upgrade runcY después recrea tus contenedores para que arranquen bajo el runtime parcheado: actualizar el binario no protege retroactivamente a los procesos que ya estaban en marcha. Este último paso es el que más gente se salta, y es el que de verdad cierra la puerta.
Parchear runc cierra Leaky Vessels, pero los mismos hábitos amortiguan el próximo CVE del runtime —porque lo habrá—:
--privileged.docker build de Dockerfiles aleatorios en una máquina que te importe.Los runtimes de contenedor son un blanco en movimiento, y los avisos de runc, containerd y Docker llegan con regularidad. CVE-2024-21626 está parcheado desde hace tiempo, pero su moraleja sigue intacta: una sola release mala del runtime puede poner en riesgo a la vez todos tus hosts de contenedores. La defensa no es vigilar un CVE concreto, es la disciplina de fondo —parcheo al día, mínimo privilegio, imágenes de confianza y radio de explosión acotado—.
En resumen, para CVE-2024-21626: si hay un binario de runc en cualquier rincón de tu parque Proxmox, llévalo a 1.1.12 o superior, recrea tus contenedores y apóyate de aquí en adelante en configuraciones unprivileged y de mínima confianza. Esa misma disciplina es la que aplicamos cuando diseñamos y operamos cloud privado sobre Proxmox y la base de cualquier postura de ciberseguridad seria sobre contenedores.
¿Qué es CVE-2024-21626 (Leaky Vessels)? Un escape de contenedor en runc, el runtime que usan Docker, containerd y Kubernetes. Una fuga de descriptor de fichero permitía a un proceso del contenedor operar sobre el sistema de ficheros del host y, en el peor caso, lograr compromiso total del anfitrión. CVSS 3.1 de 8.6 (Alta).
¿Afecta a los contenedores LXC de Proxmox? No directamente: los LXC nativos usan liblxc, no runc. El riesgo aparece cuando instalas Docker u otro runtime OCI dentro de una VM, de un LXC o en el host.
¿Cómo sé si soy vulnerable y cómo lo arreglo?
Comprueba runc --version. Si está por debajo de 1.1.12, actualiza Docker/containerd/runc y recrea los contenedores para que usen el binario parcheado.
¿Basta con actualizar el binario de runc? No. Los procesos ya en marcha siguen usando el runtime antiguo hasta que recreas el contenedor. Actualizar y recrear van juntos.
¿Cómo reduzco el riesgo de futuros CVE de runtime? Contenedores sin privilegios, imágenes de confianza con digests fijados, cargas de riesgo en VMs dedicadas en lugar de LXC pegados al host, y actualizaciones regulares del motor de contenedores y del sistema.
Fuentes: NVD — CVE-2024-21626, aviso de seguridad de runc (GHSA-xr7r-f8xq-vfvv) y el anuncio de Leaky Vessels de Snyk.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.