sofianehamlaoui/cve-2022-0492-checkerUn script para comprobar si un entorno de contenedores es vulnerable a escapes de contenedores mediante CVE-2022-0492
Un script para comprobar si un entorno de contenedores es vulnerable a escapes de contenedores mediante CVE-2022-0492
El 4 de febrero, Linux anunció CVE-2022-0492, una nueva vulnerabilidad de escalada de privilegios en el kernel.
CVE-2022-0492 marca un error lógico en los grupos de control (cgroups), una característica de Linux que es un componente fundamental de los contenedores. El problema destaca como una de las escaladas de privilegios de Linux más simples descubiertas en tiempos recientes: el kernel de Linux expuso por error una operación privilegiada a usuarios sin privilegios.
Afortunadamente, los endurecimientos de seguridad predeterminados en la mayoría de los entornos de contenedores son suficientes para prevenir el escape de contenedores. Los contenedores que se ejecutan con AppArmor o SELinux están protegidos. Dicho esto, si ejecuta contenedores sin las prácticas recomendadas de endurecimiento, o con privilegios adicionales, puede estar en riesgo. La sección "¿Estoy afectado?" enumera las configuraciones de contenedores vulnerables y proporciona instrucciones sobre cómo probar si un entorno de contenedores es vulnerable.
Además de los contenedores, la vulnerabilidad también puede permitir que procesos host root sin capacidades, o procesos host no root con la capacidad CAP_DAC_OVERRIDE, escalen privilegios y alcancen todas las capacidades. Esto puede permitir a los atacantes eludir una medida de endurecimiento utilizada por ciertos servicios, que eliminan capacidades en un intento de limitar el impacto si se produce un compromiso.
CVE-2022-0492 es ahora la tercera vulnerabilidad del kernel en los últimos meses que permite a los contenedores maliciosos escapar. En las tres vulnerabilidades, asegurar los contenedores con Seccomp y AppArmor o SELinux fue suficiente para prevenir el escape de contenedores.
Montar un cgroupfs requiere la capacidad CAP_SYS_ADMIN en el espacio de nombres de usuario que aloja el espacio de nombres de cgroup actual. Por defecto, los contenedores se ejecutan sin CAP_SYS_ADMIN, y por lo tanto no pueden montar cgroupfs en el espacio de nombres de usuario inicial. Pero a través de la llamada al sistema unshare(), los contenedores pueden crear nuevos espacios de nombres de usuario y de cgroup donde poseen la capacidad CAP_SYS_ADMIN y pueden montar un cgroupfs.
Fig. 1 - Un contenedor creando un nuevo espacio de nombres de usuario donde tendrá la capacidad CAP_SYS_ADMIN.
No todos los contenedores pueden crear un nuevo espacio de nombres de usuario: el host subyacente debe tener habilitados los espacios de nombres de usuario sin privilegios. Este es el valor predeterminado en las versiones recientes de Ubuntu, por ejemplo. Dado que Seccomp bloquea la llamada al sistema unshare(), solo los contenedores que se ejecutan sin Seccomp pueden crear un nuevo espacio de nombres de usuario. El contenedor que se muestra en la captura de pantalla adjunta se ejecuta sin Seccomp, AppArmor o SELinux.
Fig. 2 - El contenedor monta el cgroup de memoria en los nuevos espacios de nombres de usuario y de cgroup.
En la captura de pantalla anterior, el contenedor montó con éxito un cgroup de memoria, ¡pero puede notar que el archivo release_agent no está incluido en el directorio montado!
Como se mencionó anteriormente, el archivo release_agent solo es visible en el cgroup raíz. Una limitación de montar un cgroupfs en un espacio de nombres de cgroup es que se monta el cgroup al que pertenece, no el cgroup raíz.
Fig. 3 - El contenedor montando el cgroup RDMA raíz en los nuevos espacios de nombres de usuario y de cgroup.
Para explotar el problema, necesitamos escribir un agente de liberación malicioso en el archivo release_agent. Como se ve en la Fig. 3 anterior, ese archivo es propiedad de root, por lo que solo los procesos de contenedor root pueden establecer el agente de liberación. La Fig. 4 muestra el contenedor estableciendo el agente de liberación, mientras que la Fig. 5 muestra un contenedor no root que falla al hacerlo.
Fig. 4 - Un contenedor root estableciendo el agente de liberación.
Fig. 5 - Un contenedor no root no puede establecer el agente de liberación.
El paso final del escape es invocar el release_agent configurado, lo cual no requiere ningún privilegio. Dado que este paso siempre se puede realizar, no tiene implicaciones sobre si un entorno es vulnerable a CVE-2022-0492, por lo que decidimos omitirlo. Aún puede ver cómo se ve un exploit completo en la captura de pantalla a continuación.
Fig. 6 - Explotando CVE-2022-0492 para el escape de contenedores, mediante espacios de nombres de usuario.
En lugar de crear nuevos espacios de nombres de usuario y de cgroup, es posible un exploit más simple si al contenedor se le otorga la capacidad CAP_SYS_ADMIN. A un contenedor que se ejecuta con la capacidad CAP_SYS_ADMIN se le permite montar cgroupfs, sin preguntas. Como beneficio adicional, la mayoría de los contenedores hoy en día se ejecutan sin espacios de nombres de cgroup, lo que significa que el cgroup montado sería el cgroup raíz que aloja el archivo release_agent.
Fig. 7 - En el espacio de nombres de cgroup inicial, montar cgroupfs siempre montará el cgroup raíz, independientemente del cgroup del contenedor.
Incluso con la capacidad CAP_SYS_ADMIN, AppArmor y SELinux aún impiden el montaje, por lo que los contenedores que se ejecutan con cualquiera de ellos no pueden explotar CVE-2022-0492. La Fig. 8 muestra un contenedor que se ejecuta sin AppArmor y SELinux, y con la capacidad CAP_SYS_ADMIN, explotando CVE-2022-0492 para escapar.
Fig. 8 - Explotando CVE-2022-0492 para el escape de contenedores mediante la capacidad CAP_SYS_ADMIN.
CVE-2022-0492 marca otra vulnerabilidad de Linux que puede ser explotada para el escape de contenedores. Afortunadamente, los entornos que siguen las mejores prácticas están protegidos contra esta vulnerabilidad. Los entornos con controles de seguridad laxos que alojan contenedores no confiables o expuestos públicamente están, como era de esperar, en alto riesgo. Como siempre, es mejor actualizar sus hosts a una versión de kernel corregida.
Recomendamos encarecidamente ejecutar contenedores con Seccomp y AppArmor o SELinux habilitados, para protegerse contra esta vulnerabilidad y contra futuras vulnerabilidades de día cero de Linux. Muchas vulnerabilidades de escalada de privilegios en el kernel de Linux solo pueden explotarse para el escape de contenedores cuando al contenedor se le permite crear un nuevo espacio de nombres de usuario, o en otras palabras, cuando el contenedor se ejecuta sin Seccomp.
© 2022 - No Sofiane Hamlaooui - Haciendo del mundo un lugar mejor 🌎
