Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Grave fallo en los sandboxes de Docker permite que código malicioso de invitados lea y modifique archivos del host en macOS


Docker advirtió sobre dos vulnerabilidades críticas en Docker Sandboxes que permitirían a código malicioso escapar de la máquina virtual y acceder a archivos o sockets del host. El fallo más grave afecta a macOS y podría derivar en la ejecución de código en el sistema anfitrión. Se recomienda actualizar a la versión 0.42.0 o superior, o utilizar el modo clone para mitigar el riesgo.

Docker banner





El código malicioso que se ejecuta dentro de una máquina virtual de Docker Sandboxes en macOS podría escapar del directorio del proyecto compartido y leer o cambiar archivos en cualquier otro lugar del host, advierte Docker en un anuncio de seguridad el 15 de septiembre.

El escape se ejecuta con los derechos de la cuenta del host que ejecuta la máquina virtual. El fallo, CVE-2026-77179, está calificado como Crítico, afecta a las versiones 0.28.0 hasta la 0.42.0 (sin incluirla) en macOS, y fue solucionado en la versión 0.42.0 el 7 de septiembre.

Docker Sandboxes ejecuta cada agente de codificación de IA en su propia máquina virtual pequeña con el directorio del proyecto compartido. El código que podría escapar es cualquier cosa que se ejecute dentro de esa máquina, como un agente de codificación que haya sido vuelto contra su usuario, o cualquier cosa maliciosa que el agente instale y ejecute.

Docker no ha informado de ninguna explotación. La evaluación adicional de CISA sobre el registro del CVE indica que no ha habido explotación, y el fallo no figura en el catálogo de Vulnerabilidades Conocidas Explotadas de CISA hasta la versión del catálogo publicada el 16 de septiembre.

El fallo requiere código malicioso dentro del sandbox, y proteger el host de lo que ejecuta un agente es precisamente para lo que sirve el sandbox. El agente instala paquetes y ejecuta comandos con sudo dentro de la máquina virtual, y la documentación de aislamiento de Docker dice que el límite del hipervisor "es el control de aislamiento, no la separación de privilegios dentro de la VM".

El escape ocurre a través del servidor host virtio-fs, el lado del host del intercambio de archivos entre el Mac y la máquina virtual, que seguía enlaces simbólicos al reabrir un archivo eliminado desde una ruta almacenada, afirmó Docker.

Un invitado, es decir, cualquier cosa que se ejecute dentro de la máquina virtual, podría reemplazar un directorio padre con un enlace simbólico y luego leer o cambiar archivos como el usuario VMM, la cuenta del host bajo la cual se ejecuta el monitor de la máquina virtual, dijo Docker, "lo que potencialmente podría llevar a la ejecución de código en el host".

La documentación de Docker ha indicado desde marzo que los enlaces simbólicos que apuntan fuera del espacio de trabajo (el término de Docker para el directorio del proyecto compartido) no se siguen.

La misma versión soluciona un segundo fallo, CVE-2026-79994, calificado como Alto por Docker con una puntuación CVSS de 8.7, en el relé que permite a un sandbox conectarse a sockets de dominio Unix dentro de su espacio de trabajo autorizado.

El relé comprobaba que una ruta de socket estuviera dentro del espacio de trabajo y luego se reconectaba utilizando el nombre de la ruta. Un invitado que reemplazara un directorio a lo largo de esa ruta con un enlace simbólico entre la comprobación y la conexión podría hacer que el host se conectara a cualquier socket AF_UNIX fuera del espacio de trabajo, dijo Docker, "exponiendo datos o capacidades del lado del host proporcionadas por ese socket".

Ese fallo afecta a las versiones 0.37.0 hasta la 0.41.9, pero no a la 0.42.0. Docker enumera el primer fallo solo para macOS pero no especifica plataforma para este último, aunque Docker Sandboxes se ejecuta en hosts de macOS, Windows y Linux. La evaluación de CISA también indica que no hay explotación y tampoco está en el catálogo KEV.


Versiones afectadas y qué instalar



  • CVE Componente Versiones afectadas Plataforma Calificación Docker
  • CVE-2026-77179 servidor host virtio-fs 0.28.0 hasta (pero no incluyendo) 0.42.0 macOS Crítica, CVSS 9.4
  • CVE-2026-79994 relé de socket Unix invitado-a-host 0.37.0 hasta (pero no incluyendo) 0.42.0 No especificada Alta, CVSS 8.7

1. Actualiza a la versión 0.42.0 o posterior. A fecha de 17 de septiembre, la versión más reciente es la 0.43.0, publicada el 15 de septiembre.
2. Si aún no puedes actualizar, utiliza el modo clone y evita añadir montajes de host de lectura-escritura. Ese es el consejo de Docker para ambos fallos.

Por defecto, sbx run comparte el directorio actual en el sandbox con acceso de lectura y escritura. El modo clone funciona solo cuando el proyecto es un repositorio Git, y se configura cuando se crea el sandbox, por lo que un sandbox existente debe eliminarse y crearse de nuevo con --clone.

El modo clone protege el repositorio de cambios, no de la lectura. El repositorio se monta como solo lectura en /run/sandbox/source, y los archivos no rastreados como .env siguen siendo legibles dentro del sandbox, dice la documentación de Docker.

Docker publicó los registros de CVE y el aviso el 15 de septiembre, ocho días después del lanzamiento de la versión 0.42.0.

Las notas de la versión 0.42.0 en GitHub y en el sitio de documentación de Docker no mencionan ningún CVE a fecha de 17 de septiembre. Entre las correcciones rutinarias, enumeran una para "un proceso en sandbox podría lograr que el daemon abra un transporte D-Bus del host y ejecute un comando arbitrario en el host". Docker no ha vinculado esa corrección con ninguno de los CVE.

El registro de CVE-2026-79994 inicialmente enumeró la versión 0.41.0 como la primera versión corregida y enlazó a una página de lanzamiento de la 0.41.0 que no existe. Docker corrigió ambos datos a 0.42.0 aproximadamente una hora después de publicar el registro el 15 de septiembre.

Docker acredita a Oren Yomtov de accomplish.ai por encontrar el CVE-2026-77179 y a Jurre van Bergen de ThreatNotify por encontrar el CVE-2026-79994.

En abril, Cyera Research Labs describió cómo un agente de codificación con inyección de prompts dentro de un sandbox basado en Docker podría ser engañado para explotar un fallo separado de Docker Engine contra su host.

Fuente:
THN

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.