Vulnerabilidades en Docker y otros motores de contenedores permiten el acceso al sistema operativo 'host'

Los investigadores de seguridad han encontrado cuatro vulnerabilidades en los componentes de Docker que podrían permitir a los atacantes acceder a los sistemas operativos host desde dentro de los mismos. Una de estas está en runc, una herramienta de línea de comandos para generar y ejecutar contenedores en Linux que sustenta múltiples motores, y no solo Docker.

Rory McNamara, investigador de Snyk, ha sido el descubridor de los fallos, denominados como Leaky Vessels porque permiten romper la capa de aislamiento crítica entre los contenedores y el sistema operativo. “Estos escapes podrían permitir  obtener acceso no autorizado al sistema operativo host subyacente desde dentro del contenedor, y potencialmente permitir el acceso a datos confidenciales como credenciales, información del usuario, etc y lanzar más ataques, especialmente cuando el acceso obtenido incluye privilegios de superusuario”.

La vulnerabilidad proporciona múltiples rutas de ataque desde runc

Runc puede verse como la conexión que vincula la mayoría de los motores de administración de contenedores, como Docker, Containerd, Podman y CRI-O, con las funciones de espacio aislado del kernel de Linux: grupos de control, espacios de nombres, seccomp, apparmor, etc. Admite múltiples comandos para iniciar, detener, suspender, pausar y enumerar contenedores, así como ejecutar procesos dentro de contenedores.

La vulnerabilidad runc encontrada por McNamara, rastreada como CVE-2024-21626, se debe a que un descriptor de archivo se filtró inadvertidamente internamente dentro de runc, incluido un identificador para el grupo /sys/fs/cgroup del host. Esto se puede explotar de múltiples maneras, una encontrada por McNamara y otras tres encontradas por los mantenedores de runc.

“Si el contenedor se configuró para tener Process.cwd configurado en /proc/self/fd/7/ (el fd real puede cambiar según el orden de apertura de los archivos en runc), el proceso pid1 resultante tendrá un directorio de trabajo en el montaje del host. espacio de nombres y, por lo tanto, el proceso generado puede acceder a todo el sistema de archivos del host”, advierten los mantenedores de runc en un aviso. “Esto por sí solo no es una hazaña contra runc. Sin embargo, una imagen maliciosa podría convertir cualquier ruta que no sea / de apariencia inocua en un enlace simbólico a /proc/self/fd/7/ y así engañar a un usuario para que inicie un contenedor cuyo binario tenga acceso al sistema de archivos del host”.

Este exploit tiene como objetivo el comando runc run, que se utiliza para crear e iniciar un nuevo contenedor a partir de una imagen. Muchos contenedores se inician a partir de imágenes descargadas de repositorios públicos como Docker Hub y con el tiempo se han cargado imágenes maliciosas en el registro.

Otra variación del ataque involucra runc exec, que se utiliza para iniciar un proceso dentro de un contenedor existente. Esto requiere que el atacante sepa que un proceso administrativo llama a runc exec con el argumento -cwd y una ruta específica y luego reemplaza esa ruta con un enlace simbólico al descriptor de archivo /proc/self/fd/7.

Un tercer ataque implica el uso de la técnica runc run o runc exec para sobrescribir archivos binarios del sistema operativo host, como /bin/bash, el shell de Linux. Estas dos variaciones se conocen como ataques 3a y 3b.

"Estrictamente hablando, si bien el ataque 3a es el más grave desde una perspectiva CVSS, los ataques 2 y 3b son posiblemente más peligrosos en la práctica porque permiten una ruptura desde el interior de un contenedor en lugar de requerir que un usuario ejecute una imagen maliciosa", el runc dijeron los mantenedores.

Sin embargo, esto depende del contexto. Por ejemplo, en entornos de ejecución de nivel superior como Docker o Kubernetes, cualquier persona con derechos para iniciar una imagen de contenedor puede ejecutar el exploit de forma remota. El ataque también se puede iniciar utilizando la función ONBUILD en Dockerfiles.

Si bien runc es probablemente el tiempo de ejecución de contenedores más popular y utilizado debido a su asociación con Docker, no es el único tiempo de ejecución de contenedores disponible. Los mantenedores de runc advierten que creen que otros runtimes son potencialmente vulnerables a ataques similares o no tienen suficiente protección contra ellos.

Cómo mitigar la vulnerabilidad Docker runc

Además de la vulnerabilidad runc, que se solucionó en el runc 1.1.12 recién lanzado, McNamara también encontró vulnerabilidades de escape de contenedores en otros componentes de Docker como BuildKit (CVE-2024-23652 y CVE-2024-23653) y una condición de carrera de caché. (CVE-2024-23651).

"Busque anuncios del proveedor de sus sistemas de orquestación y construcción de contenedores con respecto a actualizaciones para abordar la solución o declaraciones en casos en los que no se vean afectados", dijeron los investigadores de Snyk. "Esto probablemente signifique actualizar sus demonios Docker y las implementaciones de Kubernetes, así como cualquier herramienta de creación de contenedores que utilice en las canalizaciones de CI/CD, en los servidores de compilación y en las estaciones de trabajo de sus desarrolladores".

Snyk también desarrolló dos herramientas de código abierto que permiten a los usuarios monitorear sus contenedores en busca de signos de intentos de explotación. Uno es un escáner en tiempo de ejecución que utiliza ganchos eBPF para monitorear invocaciones sospechosas de compilación de contenedores y comandos en ejecución que coincidan con los patrones de este exploit y el otro es un escáner estático para Dockerfiles e imágenes .