docker.io: CVE-2024-29018

Debian Bug report logs - #1068460
docker.io: CVE-2024-29018

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: submit@bugs.debian.org

Subject: docker.io: CVE-2024-29018

Date: Fri, 5 Apr 2024 16:53:19 +0200

Source: docker.io
X-Debbugs-CC: team@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for docker.io.

CVE-2024-29018[0]:
| Moby is an open source container framework that is a key component
| of Docker Engine, Docker Desktop, and other distributions of
| container tooling or runtimes. Moby's networking implementation
| allows for many networks, each with their own IP address range and
| gateway, to be defined. This feature is frequently referred to as
| custom networks, as each network can have a different driver, set of
| parameters and thus behaviors. When creating a network, the
| `--internal` flag is used to designate a network as _internal_. The
| `internal` attribute in a docker-compose.yml file may also be used
| to mark a network _internal_, and other API clients may specify the
| `internal` parameter as well.  When containers with networking are
| created, they are assigned unique network interfaces and IP
| addresses. The host serves as a router for non-internal networks,
| with a gateway IP that provides SNAT/DNAT to/from container IPs.
| Containers on an internal network may communicate between each
| other, but are precluded from communicating with any networks the
| host has access to (LAN or WAN) as no default route is configured,
| and firewall rules are set up to drop all outgoing traffic.
| Communication with the gateway IP address (and thus appropriately
| configured host services) is possible, and the host may communicate
| with any container IP directly.  In addition to configuring the
| Linux kernel's various networking features to enable container
| networking, `dockerd` directly provides some services to container
| networks. Principal among these is serving as a resolver, enabling
| service discovery, and resolution of names from an upstream
| resolver.  When a DNS request for a name that does not correspond to
| a container is received, the request is forwarded to the configured
| upstream resolver. This request is made from the container's network
| namespace: the level of access and routing of traffic is the same as
| if the request was made by the container itself.  As a consequence
| of this design, containers solely attached to an internal network
| will be unable to resolve names using the upstream resolver, as the
| container itself is unable to communicate with that nameserver. Only
| the names of containers also attached to the internal network are
| able to be resolved.  Many systems run a local forwarding DNS
| resolver. As the host and any containers have separate loopback
| devices, a consequence of the design described above is that
| containers are unable to resolve names from the host's configured
| resolver, as they cannot reach these addresses on the host loopback
| device. To bridge this gap, and to allow containers to properly
| resolve names even when a local forwarding resolver is used on a
| loopback address, `dockerd` detects this scenario and instead
| forward DNS requests from the host namework namespace. The loopback
| resolver then forwards the requests to its configured upstream
| resolvers, as expected.  Because `dockerd` forwards DNS requests to
| the host loopback device, bypassing the container network
| namespace's normal routing semantics entirely, internal networks can
| unexpectedly forward DNS requests to an external nameserver. By
| registering a domain for which they control the authoritative
| nameservers, an attacker could arrange for a compromised container
| to exfiltrate data by encoding it in DNS queries that will
| eventually be answered by their nameservers.  Docker Desktop is not
| affected, as Docker Desktop always runs an internal resolver on a
| RFC 1918 address.  Moby releases 26.0.0, 25.0.4, and 23.0.11 are
| patched to prevent forwarding any DNS requests from internal
| networks. As a workaround, run containers intended to be solely
| attached to internal networks with a custom upstream address, which
| will force all upstream DNS queries to be resolved from the
| container's network namespace.

https://github.com/moby/moby/security/advisories/GHSA-mq39-4gv4-mvpx
https://github.com/moby/moby/pull/46609


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-29018
    https://www.cve.org/CVERecord?id=CVE-2024-29018

Please adjust the affected versions in the BTS as needed.

Send a report that this bug log contains spam.