8 min de lectura<\/p>\n
Los contenedores parecen habitaciones aisladas, pero todos comparten el mismo kernel del host. Precisamente esta capa compartida es el verdadero l\u00edmite 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\u00e9cada latente en el c\u00f3digo y que, desde un \u00fanico contenedor comprometido, abre de par en par todo el nodo subyacente.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado:<\/span>Vulnerabilidades del kernel de Linux: el BSI advierte sobre la escalada de root<\/a> \/<\/span> Por qu\u00e9 la misma clase de vulnerabilidad siempre vuelve a aparecer<\/a><\/p>\n Un contenedor encapsula procesos, sistemas de archivos y redes, pero no incluye su propio kernel. A diferencia de una m\u00e1quina virtual, se ejecuta directamente sobre el kernel del host y lo comparte con todos los dem\u00e1s contenedores de la misma m\u00e1quina. Esta capa com\u00fan es la raz\u00f3n de la ligereza de los contenedores y, al mismo tiempo, su punto m\u00e1s vulnerable. Quien compromete el kernel ya no est\u00e1 en un contenedor, sino en el host.<\/p>\n Copy Fail aprovecha precisamente esta circunstancia. El kernel de Linux gestiona una cach\u00e9 de p\u00e1ginas compartida globalmente que se aplica a trav\u00e9s de los l\u00edmites de los contenedores, sin su propia separaci\u00f3n de espacios de nombres. Un proceso sin privilegios en un contenedor puede aprovechar la vulnerabilidad para escribir unos pocos bytes controlados en la cach\u00e9 de un archivo legible para \u00e9l y, de este modo, obtener privilegios de root. Dado que la cach\u00e9 es compartida, el acceso de escritura llega hasta el host y se extiende a otros contenedores.<\/p>\n \u00bfQu\u00e9 es un escape de contenedor?<\/strong> 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\u00e9s del kernel compartido: quien explota una vulnerabilidad all\u00ed, elude la separaci\u00f3n que el contenedor parece garantizar.<\/p>\n Copy Fail no es un error de programaci\u00f3n nuevo, sino que estaba presente desde el kernel 4.14, es decir, hace unos nueve a\u00f1os. No es un caso aislado, sino un patr\u00f3n: clases de errores sobreviven mucho tiempo en el c\u00f3digo porque nadie las busca espec\u00edficamente hasta que alguien lo hace. El cambio decisivo no es la edad, sino el momento de la publicaci\u00f3n. En cuanto circula un exploit funcional, la competencia necesaria del atacante se reduce dr\u00e1sticamente.<\/p>\n Para los operadores de plataformas de contenedores, esto cambia la urgencia. Una vulnerabilidad que durante a\u00f1os fue te\u00f3rica se convierte en un peligro agudo con la publicaci\u00f3n del c\u00f3digo. Esto es especialmente cierto en entornos con carga mixta, donde se ejecuta c\u00f3digo poco fiable junto a servicios sensibles en el mismo nodo. Ah\u00ed, el escape del contenedor no es un riesgo abstracto, sino el camino directo desde la carga de trabajo insignificante hasta el nodo entero.<\/p>\n La lecci\u00f3n m\u00e1s importante es conceptual: el contenedor es un l\u00edmite operativo, no una frontera de seguridad r\u00edgida contra fallos del kernel. Quien acepta esto construye una defensa en capas en lugar de basarse en una \u00fanica suposici\u00f3n. La disciplina de parches es lo primero, porque contra una vulnerabilidad conocida con un exploit p\u00fablico, lo que m\u00e1s ayuda es la correcci\u00f3n aplicada.<\/p>\n Falsa seguridad<\/p>\n Defensa multicapa<\/p>\n Adem\u00e1s, est\u00e1 la limitaci\u00f3n 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\u00f3n 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\u00e9 deben ir de la mano.<\/p>\n A\u00edslan de forma diferente. Una m\u00e1quina 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\u00e1s s\u00f3lida. A cambio, los contenedores son m\u00e1s ligeros y r\u00e1pidos. La elecci\u00f3n correcta depende del nivel de confianza de las cargas de trabajo.<\/p>\n 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\u00e9, no protege si el kernel subyacente sigue siendo vulnerable.<\/p>\n Un perfil seccomp restringe qu\u00e9 llamadas al sistema puede utilizar un contenedor. Muchos exploits del kernel necesitan determinadas syscalls para alcanzar la ruta vulnerable. Si estas est\u00e1n bloqueadas, el ataque no surte efecto, aunque la vulnerabilidad en s\u00ed siga existiendo.<\/p>\n Porque la b\u00fasqueda dirigida es poco frecuente. Las clases de errores sobreviven mucho tiempo sin ser detectadas hasta que un investigador echa un vistazo m\u00e1s detallado. La antig\u00fcedad no indica el nivel de peligro. Solo la publicaci\u00f3n del exploit convierte una vulnerabilidad te\u00f3rica en un riesgo agudo.<\/p>\n Aquellos con carga mixta, donde poco c\u00f3digo confiable se ejecuta junto a servicios sensibles en el mismo nodo. All\u00ed 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.<\/p>\n\n
La capa compartida que nadie ve<\/h2>\n
Por qu\u00e9 la antig\u00fcedad de la vulnerabilidad no es motivo para bajar la guardia<\/h2>\n
Lo que realmente protege<\/h2>\n
\n
\n
Preguntas frecuentes<\/h2>\n
\u00bfSon los contenedores menos seguros que las m\u00e1quinas virtuales?<\/h3>\n
\u00bfAyuda una imagen de contenedor actualizada contra Copy Fail?<\/h3>\n
\u00bfQu\u00e9 aporta seccomp contra los exploits del kernel?<\/h3>\n
\u00bfPor qu\u00e9 se detectan estos errores solo despu\u00e9s de a\u00f1os?<\/h3>\n
\u00bfQu\u00e9 entornos son especialmente peligrosos?<\/h3>\n