Vulnerabilidad en Moby (CVE-2024-29018)
Fecha de publicación:
20/03/2024
Moby es un marco de contenedores de código abierto que es un componente clave de Docker Engine, Docker Desktop y otras distribuciones de herramientas o tiempos de ejecución de contenedores. La implementación de redes de Moby permite definir muchas redes, cada una con su propio rango de direcciones IP y puerta de enlace. Esta característica se conoce frecuentemente como redes personalizadas, ya que cada red puede tener un controlador, un conjunto de parámetros y, por lo tanto, comportamientos diferentes. Al crear una red, el indicador `--internal` se utiliza para designar una red como _internal_. El atributo "interno" en un archivo docker-compose.yml también se puede usar para marcar una red como _interna_, y otros clientes API también pueden especificar el parámetro "interno". Cuando se crean contenedores con redes, se les asignan interfaces de red y direcciones IP únicas. El host sirve como enrutador para redes no internas, con una IP de puerta de enlace que proporciona SNAT/DNAT hacia/desde las IP del contenedor. Los contenedores en una red interna pueden comunicarse entre sí, pero no pueden comunicarse con ninguna red a la que el host tenga acceso (LAN o WAN), ya que no hay una ruta predeterminada configurada y las reglas de firewall están configuradas para eliminar todo el tráfico saliente. Es posible la comunicación con la dirección IP de la puerta de enlace (y, por lo tanto, con los servicios de host configurados adecuadamente), y el host puede comunicarse directamente con cualquier IP de contenedor. Además de configurar las diversas funciones de red del kernel de Linux para habilitar la red de contenedores, `dockerd` proporciona directamente algunos servicios a las redes de contenedores. El principal de ellos es servir como solucionador, permitiendo el descubrimiento de servicios y la resolución de nombres desde un solucionador ascendente. Cuando se recibe una solicitud de DNS para un nombre que no corresponde a un contenedor, la solicitud se reenvía al solucionador ascendente configurado. Esta solicitud se realiza desde el espacio de nombres de la red del contenedor: el nivel de acceso y enrutamiento del tráfico es el mismo que si la solicitud la realizara el propio contenedor. Como consecuencia de este diseño, los contenedores conectados únicamente a una red interna no podrán resolver nombres utilizando el solucionador ascendente, ya que el contenedor en sí no puede comunicarse con ese servidor de nombres. Sólo se pueden resolver los nombres de los contenedores también conectados a la red interna. Muchos sistemas ejecutan un solucionador de DNS de reenvío local. Como el host y cualquier contenedor tienen dispositivos de loopback separados, una consecuencia del diseño descrito anteriormente es que los contenedores no pueden resolver nombres desde el solucionador configurado del host, ya que no pueden alcanzar estas direcciones en el dispositivo de loopback del host. Para cerrar esta brecha y permitir que los contenedores resuelvan nombres correctamente incluso cuando se utiliza un solucionador de reenvío local en una dirección de loopback, `dockerd` detecta este escenario y en su lugar reenvía solicitudes DNS desde el espacio de nombres del trabajo de nombres del host. Luego, el solucionador de bucle invertido reenvía las solicitudes a sus solucionadores ascendentes configurados, como se esperaba. Debido a que `dockerd` reenvía solicitudes de DNS al dispositivo de bucle invertido del host, omitiendo por completo la semántica de enrutamiento normal del espacio de nombres de la red del contenedor, las redes internas pueden reenviar solicitudes de DNS inesperadamente a un servidor de nombres externo. Al registrar un dominio para el cual controlan los servidores de nombres autorizados, un atacante podría hacer que un contenedor comprometido extraiga datos codificándolos en consultas DNS que eventualmente serán respondidas por sus servidores de nombres.---TRUNCADO---
Gravedad CVSS v3.1: MEDIA
Última modificación:
09/04/2025
