CVE-2024-29018: Moby Information Disclosure Vulnerability

CVE-2024-29018 Overview

CVE-2024-29018 is a DNS vulnerability affecting Moby, the open source container framework that serves as a key component of Docker Engine, Docker Desktop, and other container tooling distributions. The vulnerability exists in Moby's networking implementation when handling DNS requests from containers attached to internal networks, potentially allowing attackers to exfiltrate data through DNS queries.

When creating Docker networks with the --internal flag or the internal attribute in docker-compose.yml files, containers are expected to be isolated from external networks. However, due to a design flaw in how dockerd handles DNS requests when a local forwarding resolver is detected on the host's loopback device, DNS requests from internal networks can unexpectedly be forwarded to external nameservers, bypassing the intended network isolation.

Critical Impact

Compromised containers on internal networks can exfiltrate sensitive data by encoding it in DNS queries to attacker-controlled nameservers, completely bypassing the network isolation guarantees that internal networks are designed to provide.

Affected Products

• Moby versions prior to 23.0.11
• Moby versions 24.0.0 through 25.0.3
• Moby versions 26.0.0-rc1, 26.0.0-rc2, and 26.0.0-rc3

Discovery Timeline

• 2024-03-20 - CVE-2024-29018 published to NVD
• 2025-04-09 - Last updated in NVD database

Technical Details for CVE-2024-29018

Vulnerability Analysis

This vulnerability represents a DNS-based data exfiltration weakness (CWE-669: Incorrect Resource Transfer Between Spheres) in Moby's container networking architecture. The issue stems from how dockerd handles DNS resolution for containers when the host system uses a local forwarding DNS resolver on a loopback address.

Under normal operation, containers on internal networks should be unable to communicate with external networks, as no default route is configured and firewall rules drop all outgoing traffic. However, dockerd provides DNS services directly to container networks, acting as a resolver for service discovery and upstream name resolution.

When dockerd detects that the host's configured DNS resolver is on a loopback address (a common configuration for local forwarding resolvers), it bridges the gap by forwarding DNS requests from the host network namespace instead of the container's namespace. This design decision, intended to ensure containers can properly resolve names, inadvertently breaks the isolation guarantees of internal networks.

Root Cause

The root cause is the DNS forwarding mechanism in dockerd that bypasses the container network namespace's routing semantics when a loopback resolver is detected on the host. When forwarding DNS requests from internal network containers, dockerd incorrectly forwards these requests through the host namespace rather than respecting the internal network's isolation boundaries. This allows DNS traffic to escape the internal network through the host's resolver infrastructure.

Attack Vector

An attacker who has compromised a container on an internal network can exploit this vulnerability to exfiltrate data to external systems. The attack leverages DNS as a covert channel:

1. The attacker registers a domain and controls its authoritative nameservers
2. The compromised container encodes sensitive data into DNS query labels (e.g., sensitive-data-here.attacker-domain.com)
3. Due to the vulnerability, these DNS queries are forwarded to the host's loopback resolver
4. The local resolver forwards the queries to upstream DNS servers
5. Eventually, the queries reach the attacker's authoritative nameserver, where the encoded data can be extracted

This attack bypasses the intended network isolation because DNS traffic is handled specially by dockerd and does not follow the normal routing rules that block container-to-external communication on internal networks.

Detection Methods for CVE-2024-29018

Indicators of Compromise

• Unusual DNS query patterns from containers designated as internal-network-only
• DNS queries containing base64-encoded or hex-encoded strings in subdomain labels
• High volume of DNS queries to newly registered or suspicious domains from internal network containers
• DNS traffic originating from the host namespace on behalf of containers that should have no external network access

Detection Strategies

• Monitor DNS query logs for requests originating from containers attached to internal networks
• Implement DNS query inspection to detect data exfiltration patterns such as unusually long subdomain labels or high entropy in query names
• Deploy network monitoring to detect any unexpected outbound traffic from systems running internal Docker networks
• Audit container network configurations to identify containers on internal networks that may be vulnerable

Monitoring Recommendations

• Enable detailed DNS logging on the host's local resolver to track queries from dockerd
• Implement DNS analytics to baseline normal query patterns and alert on anomalies
• Use container runtime security tools to monitor network activity from containers on internal networks
• Consider deploying a DNS firewall or response policy zone (RPZ) to block queries to known malicious domains

How to Mitigate CVE-2024-29018

Immediate Actions Required

• Upgrade Moby to version 26.0.0, 25.0.4, or 23.0.11 or later immediately
• Review all internal network configurations and identify containers that rely on internal network isolation for security
• Implement the workaround for containers that cannot be immediately updated
• Audit existing containers on internal networks for signs of compromise

Patch Information

The Moby project has released patched versions that prevent forwarding any DNS requests from internal networks. The fix is available in the following versions:

• Moby 26.0.0 (stable release)
• Moby 25.0.4
• Moby 23.0.11

For detailed patch information, refer to the GitHub Pull Request #46609 and the GitHub Security Advisory GHSA-mq39-4gv4-mvpx.

Note: Docker Desktop is not affected by this vulnerability, as it always runs an internal resolver on an RFC 1918 address rather than relying on the host's loopback resolver.

Workarounds

• Run containers intended for internal networks with a custom upstream DNS address using the --dns flag
• Specify a non-loopback DNS server that forces all upstream DNS queries to be resolved from the container's network namespace
• Consider implementing network policies or firewall rules at the host level to block unexpected DNS traffic
• Deploy DNS monitoring and filtering solutions to detect and block data exfiltration attempts

# Workaround: Run container with custom DNS to force resolution from container namespace
docker run --network internal_network --dns 8.8.8.8 your-container-image

# Alternative: Configure in docker-compose.yml
# services:
#   your-service:
#     networks:
#       - internal_network
#     dns:
#       - 8.8.8.8