Los investigadores de seguridad han descubierto cuatro vulnerabilidades en los componentes de Docker que podrían permitir a los atacantes acceder a los sistemas operativos host desde los contenedores. Una de las vulnerabilidades está en runc, una herramienta de línea de comandos para crear y ejecutar contenedores en Linux, que es la base de varios motores de contenedores, no solo de Docker. Esta no es la primera vez que este entorno de ejecución de contenedores se ve afectado por fallas de seguridad.Las vulnerabilidades fueron descubiertas por Rory McNamara, un investigador de la empresa de seguridad Snyk, que las denominó colectivamente “Leaky Vessels” (buques con fugas) porque rompen la capa de aislamiento crítica entre los contenedores y el sistema operativo anfitrión. “Estas fugas de contenedores podrían permitir a un atacante obtener acceso no autorizado al sistema operativo anfitrión subyacente desde dentro del contenedor y potencialmente permitir el acceso a datos confidenciales (credenciales, información de clientes, etc.) y lanzar otros ataques, particularmente cuando el acceso obtenido incluye privilegios de superusuario”, dijo Snyk. En una publicación de blog.

Índice
  1. Múltiples rutas de ataque desde runc
  2. Cómo mitigar la vulnerabilidad runc de Docker

Múltiples rutas de ataque desde runc

Runc puede considerarse como la tubería que conecta la mayoría de los motores de gestión de contenedores como Docker, contenedord, Podman y CRI-O con las características de sandbox del kernel de Linux: cgroups, namespaces, seccomp, apparmor, etc. Admite múltiples comandos para iniciar, detener, suspender, pausar y enumerar contenedores, así como para ejecutar procesos dentro de los contenedores. La falla en runc descubierta por Rory McNamara, enumerada como CVE-2024-21626, se origina de un descriptor de archivo filtrado inadvertidamente internamente dentro de runc, incluido un identificador para el grupo /sys/fs/c del host. Esto se puede explotar de múltiples formas: una detectada por McNamara y otras tres encontradas por los mantenedores de runc. "Si el contenedor ha sido configurado de modo que process.cwd esté establecido en /proc/self/fd/7/ (el fd real puede cambiar dependiendo del orden en el que se abran los archivos en runc), el proceso pid1 resultante tendrá un directorio de trabajo en el espacio de nombres mount del host, y el proceso generado podrá, por lo tanto, acceder a todo el sistema de archivos del host", advierten los mantenedores de runc en una nota de advertencia. "Esto en sí mismo no es un exploit contra runc. Sin embargo, una imagen maliciosa podría hacer que cualquier ruta aparentemente inocua que no sea / sea un enlace simbólico a /proc/self/fd/7/ y, por lo tanto, engañar a un usuario para que inicie un contenedor cuyo binario tenga acceso al sistema de archivos del host". Este exploit apunta al comando run de runc, que se utiliza para crear e iniciar un 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 subido imágenes maliciosas al registro.

Otra variante del ataque implica el uso de runc exec para iniciar un proceso dentro de un contenedor existente. Para ello, el atacante debe saber que un proceso administrativo está llamando a runc exec con el argumento -cwd y una ruta específica, y luego reemplazar 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 binarios del sistema operativo host, como /bin/bash, el shell de Linux. Estas dos variantes se conocen como ataques 3a y 3b. "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 un escape desde el interior de un contenedor en lugar de requerir que un usuario ejecute una imagen maliciosa", advirtieron los mantenedores de runc. Sin embargo, depende del contexto. Por ejemplo, en entornos de ejecución de nivel superior como Docker o Kubernetes, cualquiera con permiso para iniciar una imagen de contenedor puede ejecutar el exploit de forma remota. El ataque también se puede lanzar utilizando la función ONBUILD en los archivos Docker. Si bien runc es probablemente el entorno de ejecución de contenedores más popular y ampliamente utilizado debido a su asociación con Docker, no es el único disponible. Los mantenedores de runc advierten que otros entornos de ejecución son potencialmente vulnerables a ataques similares o no tienen suficiente protección contra ellos.

Cómo mitigar la vulnerabilidad runc de Docker

Además del agujero de seguridad de runc, corregido en la última versión 1.1.12, Rory 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).

“Esté atento a los anuncios de su proveedor de sistemas de implementación y orquestación de contenedores con respecto a las actualizaciones para abordar el problema o las declaraciones en los casos en que no se vean afectados”, dijeron los investigadores de Snyk. “Esto probablemente significa que necesita actualizar sus daemons de Docker y las implementaciones de Kubernetes, así como cualquier herramienta de compilación de contenedores que use en las canalizaciones de CI/CD, en los servidores de compilación y en sus estaciones de trabajo de desarrollador”. Snyk también ha desarrollado dos herramientas de código abierto que permiten a los usuarios monitorear sus contenedores en busca de señales de intentos de explotación. Uno es un escáner de tiempo de ejecución que usa ganchos eBPF para monitorear invocaciones sospechosas de comandos de compilación y tiempo de ejecución de contenedores que coinciden con los patrones de este exploit, y el otro es un escáner estático para archivos e imágenes de Docker.