Nota perev. : Anoche, Aleksa Sarai, ingeniero de contenedores senior en SUSE Linux, dijo a la lista de correo oss-sec de una vulnerabilidad de seguridad crítica runc / LXC que podría permitir a un atacante acceder a un contenedor aislado para obtener privilegios de root en el sistema host. Dado que el problema se identificó en la implementación de referencia del tiempo de ejecución del contenedor, runc, afecta a numerosos sistemas de contenedores, incluidos Docker / Moby, Podman , cri-o (y Kubernetes). Los detalles se presentan a continuación en la forma de traducir el mensaje de un ingeniero en una lista de correo.Soy uno de los mantenedores de runc (el tiempo de ejecución de contenedor subyacente utilizado por Docker, cri-o, containerd, Kubernetes, etc.). Recientemente se supo de una vulnerabilidad que verificamos y reparamos.
Investigadores que descubrieron la vulnerabilidad:
- Adam Iwaniuk;
- Borys Popławski.
Además, Aleksa Sarai (es decir, I) descubrió que el LXC también se ve afectado por una versión más sofisticada de esta vulnerabilidad.
Breve reseña
La vulnerabilidad permite que un contenedor malicioso (con mínima interacción del usuario) sobrescriba el binario del host runc y, por lo tanto, pueda ejecutar código con privilegios de root en el host. El grado de interacción del usuario es tal que le permite ejecutar cualquier comando (no importa si el atacante controla el comando) con privilegios de root dentro del contenedor en cualquiera de estos contextos:
- Crear un nuevo contenedor a partir de una imagen controlada por un atacante;
- Conexión (
docker exec ) a un contenedor existente al que el atacante tenía previamente acceso de escritura.
Esta vulnerabilidad
no está
bloqueada por la política predeterminada de AppArmor o la política predeterminada de SELinux en Fedora * (porque los procesos del contenedor parecen haber comenzado con
container_runtime_t ). Sin embargo, está
bloqueado por el uso correcto de los espacios de nombres de usuario (donde la raíz del host no se asigna al espacio de nombres de usuario del contenedor).
El vector CVSSv3 (con una calificación de 7.2) es el siguiente:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:HEl
problema se le asigna
CVE-2019-5736 .
* El problema se aplica solo al paquete moby-engine en Fedora. El paquete docker , como podman , está protegido de su funcionamiento, ya que inicia los procesos de container_t como container_t .Parches
Estoy aplicando el parche apropiado para solucionar el problema (
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch ). Se basa en la rama
HEAD , aunque el código en
libcontainer/nsenter/ cambia tan raramente que el parche probablemente se aplica a casi cualquier versión antigua de la base de código runc con la que está tratando.
Tenga en cuenta que el
parche que envío a la rama principal de runc es una versión modificada de este parche, aunque son funcionalmente idénticos (si todavía no ha parcheado sus archivos con el parche adjunto, le recomendamos que use la versión ascendente).
Código de explotación secundario
Algunos proveedores solicitaron un código de explotación para asegurarse de que los parches resolvieran el problema. Dado que el problema es muy grave (especialmente para los proveedores de nube pública), decidimos proporcionar dicho código. El exploit que escribí es más general que el código original proporcionado por los investigadores y funciona para el LXC (no requiere modificaciones fuertes para poder aplicarlo a otros entornos ejecutables vulnerables). Los detalles sobre cómo usar el código de explotación se proporcionan en
README .
De acuerdo con las reglas de OpenWall, el código de explotación se lanzará
públicamente 7 días después del CRD (es decir, 18 de febrero de 2019).
Si tiene un tiempo de ejecución de contenedor, asegúrese de que no se vea afectado por esta vulnerabilidad.Impacto en otros proyectos
Cabe señalar que en el curso de una investigación más profunda del problema, descubrí que el LXC tiene una vulnerabilidad similar, y ya presionaron un
parche similar
de nuestro desarrollo conjunto. LXC es un poco más difícil de operar, pero el problema en sí es el mismo.
Una discusión con representantes de systemd-nspawn llevó a la conclusión de que no son vulnerables (ya que tienen un método diferente para conectarse al contenedor para LXC y runc).
Los representantes de Apache Mesos también se pusieron en contacto conmigo, informando que también son vulnerables (creo que simplemente usaron el código de explotación que se publicará). Es muy probable que la mayoría de los tiempos de ejecución de los contenedores sean vulnerables si no han tomado previamente medidas muy inusuales para mitigar su impacto potencial.
Otras noticias
Hemos configurado un boletín para futuras vulnerabilidades de seguridad: el proceso de unirse a él se describe
aquí (se basa en la lista de correo de anuncios de seguridad de Kubernetes). Únase si distribuye tiempos de ejecución para contenedores que dependen de runc (u otros proyectos OCI).
PD Del traductor
Problema CVE-2019-5736 en rastreadores de distribuciones populares de Linux:
... y la
publicación del blog de Kubernetes (consulte la sección "¿Qué debo hacer?").