Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se dio a conocer la noticia del descubrimiento de nuevas vulnerabilidades en runC (una herramienta CLI para generar y ejecutar contenedores en Linux) CVE-2024-21626 y en BuildKit (CVE-2024-23651, CVE-2024-23652 y CVE-2024-23653), siendo la de mayor preocupación CVE-2024-21626, ya que es una vulnerabilidad crítica que permite el acceso al sistema de archivos del sistema operativo host.

CVE-2024-21626 permite el acceso al sistema de archivos del entorno host desde un contenedor aislado. Durante un ataque, un atacante puede sobrescribir algunos archivos ejecutables en el entorno del host y ejecutar su código fuera del contenedor.

Esto es especialmente preocupante en entornos como Kubernetes, donde los contenedores se ejecutan en nodos compartidos. Al explotar esta vulnerabilidad, un atacante puede obtener control privilegiado sobre el host, lo que potencialmente le otorga acceso no autorizado a otros pods y datos de otros en el mismo nodo.

Además, esta vulnerabilidad también afecta a los procesos de construcción que se ejecutan en entornos de contenedores, lo que brinda a los atacantes la oportunidad de establecer un punto de apoyo dentro de un proceso de construcción. Este escenario podría resultar en que un atacante obtenga credenciales con privilegios elevados, lo que le otorgaría acceso a cargas de trabajo de producción críticas u otros entornos confidenciales. En esencia, el impacto se extiende más allá de la simple fuga de información o la ejecución de código arbitrario, y podría comprometer la integridad y seguridad de todo el entorno de desarrollo y producción.

En entornos donde se utilizan Docker o Kubernetes, un ataque puede llevarse a cabo mediante una imagen de contenedor especialmente diseñada. Una vez instalada y lanzada esta imagen, el atacante puede acceder a un sistema de archivos externo desde el contenedor. En el caso de Docker, es posible operar a través de un Dockerfile especialmente diseñado. La vulnerabilidad también puede ser explotada si los procesos se inician en un contenedor usando el comando «runc exec» y vinculando el directorio de trabajo al espacio de nombres del entorno host.

El problema principal es una fuga de descriptor de archivo y, mientras hacemos O_CLOEXEC, todos los descriptores de archivos antes de ejecutar el código contenedor, el archivo descriptor está abierto al hacer setcwd(2), lo que significa que la referencia se puede mantener viva en el contenedor configurando el modo de trabajo del directorio como una ruta resuelta a través del descriptor de archivo (y el bit no volcable no está configurado después de execve(2), lo que significa que hay múltiples formas de atacar esto además de las malas configuraciones).

La causa de la vulnerabilidad radica en la filtración de descriptores de archivos internos. Antes de ejecutar el código dentro del contenedor, runc cierra todos los descriptores de archivos utilizando el indicador O_CLOEXEC. Sin embargo, las ejecuciones posteriores de setcwd() dejan abierto un descriptor de archivo que apunta al directorio de trabajo y permanece accesible después de que se inicia el contenedor. Se han propuesto varios escenarios básicos para atacar el entorno del host utilizando el descriptor de archivo restante.

Se menciona que un ejemplo de explotación de la vulnerabilidad es si un contenedor de se configuró:

Para establecerse process.cwd en /proc/self/fd/7/, el proceso pid1 resultante tendrá un directorio de trabajo en el espacio de nombres de montaje del host y, por lo tanto, el proceso generado podrá acceder a todo el sistema de archivos del host. Esto por sí solo no es un exploit contra runc. También un atacante puede engañar a un usuario para que ejecute una imagen de contenedor maliciosa, permitiendo que un proceso contenedor llegue al sistema de archivos del host a través de runc. Esto puede extenderse hasta la sobrescritura de archivos binarios del host, lo que resulta en un escape completo del contenedor. 

Finalmente, cabe mencionar que la vulnerabilidad se ha solucionado en la versión 1.1.12 de runc, por lo que la recomendación es que se realice la actualización a la nueva versión. Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.