El núcleo compartido es la brecha: por qué Copy Fail escapa del contenedor
8 min de lectura
Los contenedores parecen habitaciones aisladas, pero todos comparten el mismo kernel del host. Precisamente esta capa compartida es el verdadero límite del aislamiento, y no resiste si hay un error en el propio kernel. La vulnerabilidad Copy Fail, revelada recientemente, lo demuestra: un fallo que llevaba casi una década latente en el código y que, desde un único contenedor comprometido, abre de par en par todo el nodo subyacente.
Lo más importante en resumen
- Los contenedores no son un límite del kernel. Todos los contenedores de un host comparten su kernel. Un error en el kernel anula la aparente separación.
- Los errores antiguos siguen siendo peligrosos. Copy Fail estaba en el código desde el kernel 4.14. La antigüedad no protege; un exploit público hace que la vulnerabilidad sea relevante de inmediato.
- La defensa requiere múltiples capas. La disciplina de parches, las llamadas al sistema restringidas y una separación estricta de nodos pesan más que confiar únicamente en el límite del contenedor.
Relacionado:Vulnerabilidades del kernel de Linux: el BSI advierte sobre la escalada de root / Por qué la misma clase de vulnerabilidad siempre vuelve a aparecer
La capa compartida que nadie ve
Un contenedor encapsula procesos, sistemas de archivos y redes, pero no incluye su propio kernel. A diferencia de una máquina virtual, se ejecuta directamente sobre el kernel del host y lo comparte con todos los demás contenedores de la misma máquina. Esta capa común es la razón de la ligereza de los contenedores y, al mismo tiempo, su punto más vulnerable. Quien compromete el kernel ya no está en un contenedor, sino en el host.
Copy Fail aprovecha precisamente esta circunstancia. El kernel de Linux gestiona una caché de páginas compartida globalmente que se aplica a través de los límites de los contenedores, sin su propia separación de espacios de nombres. Un proceso sin privilegios en un contenedor puede aprovechar la vulnerabilidad para escribir unos pocos bytes controlados en la caché de un archivo legible para él y, de este modo, obtener privilegios de root. Dado que la caché es compartida, el acceso de escritura llega hasta el host y se extiende a otros contenedores.
¿Qué es un escape de contenedor? Un escape de contenedor es la fuga de un atacante desde el aislamiento de un contenedor hacia el host subyacente o hacia contenedores adyacentes. Por lo general, esto se hace posible a través del kernel compartido: quien explota una vulnerabilidad allí, elude la separación que el contenedor parece garantizar.
Por qué la antigüedad de la vulnerabilidad no es motivo para bajar la guardia
Copy Fail no es un error de programación nuevo, sino que estaba presente desde el kernel 4.14, es decir, hace unos nueve años. No es un caso aislado, sino un patrón: clases de errores sobreviven mucho tiempo en el código porque nadie las busca específicamente hasta que alguien lo hace. El cambio decisivo no es la edad, sino el momento de la publicación. En cuanto circula un exploit funcional, la competencia necesaria del atacante se reduce drásticamente.
Para los operadores de plataformas de contenedores, esto cambia la urgencia. Una vulnerabilidad que durante años fue teórica se convierte en un peligro agudo con la publicación del código. Esto es especialmente cierto en entornos con carga mixta, donde se ejecuta código poco fiable junto a servicios sensibles en el mismo nodo. Ahí, el escape del contenedor no es un riesgo abstracto, sino el camino directo desde la carga de trabajo insignificante hasta el nodo entero.
Lo que realmente protege
La lección más importante es conceptual: el contenedor es un límite operativo, no una frontera de seguridad rígida contra fallos del kernel. Quien acepta esto construye una defensa en capas en lugar de basarse en una única suposición. La disciplina de parches es lo primero, porque contra una vulnerabilidad conocida con un exploit público, lo que más ayuda es la corrección aplicada.
Falsa seguridad
- El contenedor se considera una frontera rígida
- Cargas de trabajo poco fiables junto a servicios sensibles
- Los parches del kernel se consideran no críticos
Defensa multicapa
- Aplicar los parches del kernel de forma puntual y priorizada
- Limitar estrictamente las llamadas al sistema mediante seccomp
- Separar las cargas de trabajo sensibles en nodos dedicados
Además, está la limitación de lo que un contenedor puede hacer. Un perfil de llamadas al sistema muy restrictivo priva de fundamento a muchos exploits del kernel, porque ni siquiera alcanzan la ruta vulnerable. Y donde confluyen cargas de trabajo con diferentes niveles de confianza, la separación estricta en nodos propios es imprescindible, para que un escape no arrastre inmediatamente a los vecinos sensibles. Ninguna de estas medidas es nueva, pero Copy Fail demuestra por qué deben ir de la mano.
Preguntas frecuentes
¿Son los contenedores menos seguros que las máquinas virtuales?
Aíslan de forma diferente. Una máquina virtual incluye su propio kernel; los contenedores comparten el del host. Por lo tanto, frente a fallos del kernel, la VM ofrece una frontera más sólida. A cambio, los contenedores son más ligeros y rápidos. La elección correcta depende del nivel de confianza de las cargas de trabajo.
¿Ayuda una imagen de contenedor actualizada contra Copy Fail?
No, porque la vulnerabilidad reside en el kernel del host, no en la imagen. Lo decisivo es aplicar el parche al kernel del host. Una imagen, por muy actualizada que esté, no protege si el kernel subyacente sigue siendo vulnerable.
¿Qué aporta seccomp contra los exploits del kernel?
Un perfil seccomp restringe qué llamadas al sistema puede utilizar un contenedor. Muchos exploits del kernel necesitan determinadas syscalls para alcanzar la ruta vulnerable. Si estas están bloqueadas, el ataque no surte efecto, aunque la vulnerabilidad en sí siga existiendo.
¿Por qué se detectan estos errores solo después de años?
Porque la búsqueda dirigida es poco frecuente. Las clases de errores sobreviven mucho tiempo sin ser detectadas hasta que un investigador echa un vistazo más detallado. La antigüedad no indica el nivel de peligro. Solo la publicación del exploit convierte una vulnerabilidad teórica en un riesgo agudo.
¿Qué entornos son especialmente peligrosos?
Aquellos con carga mixta, donde poco código confiable se ejecuta junto a servicios sensibles en el mismo nodo. Allí el camino desde una carga de trabajo secundaria hasta el control total del nodo es corto. Separar las cargas sensibles en nodos propios reduce significativamente este riesgo.
Más del MBF Media Netzwerk
Fuente imagen principal: Pexels / panumas nikhomkhai (px:17489157)
