Package Instance

Moby's external DNS requests from 'internal' networks could lead to data exfiltration
Moby is an open source container framework originally developed by Docker Inc. as Docker. It is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. As a batteries-included container runtime, Moby comes with a built-in networking implementation that enables communication between containers, and between containers and external resources.

Moby's networking implementation allows for creating and using many networks, each with their own subnet and gateway. 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 (typically from a non-routable [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) subnet). The root network namespace (hereafter referred to as 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 (looking up other containers on the network by name), 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 (by default, the host's configured resolver). This request is made from the container 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 _internal_ network(s) 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 will run a local forwarding DNS resolver, typically present on a loopback address (`127.0.0.0/8`), such as systemd-resolved or dnsmasq. Common loopback address examples include `127.0.0.1` or `127.0.0.53`. 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` will detect this scenario and instead forward DNS requests from the host/root network namespace. The loopback resolver will then forward the requests to its configured upstream resolvers, as expected.

## Impact

Because `dockerd` will forward 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. For example, if the domain `evil.example` was registered, the authoritative nameserver(s) for that domain could (eventually and indirectly) receive a request for `this-is-a-secret.evil.example`.

Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.

## Patches

Moby releases 26.0.0-rc3, 25.0.5 (released) and 23.0.11 (to be released) are patched to prevent forwarding DNS requests from internal networks.

## Workarounds

-   Run containers intended to be solely attached to _internal_ networks with a custom upstream address (`--dns` argument to `docker run`, or API equivalent), which will force all upstream DNS queries to be resolved from the container network namespace.

## Background

- yair zak originally reported this issue to the Docker security team.
-  PR <https://github.com/moby/moby/pull/46609> was opened in public to fix this issue, as it was not originally considered to have a security implication.
- [The official documentation](https://docs.docker.com/network/drivers/ipvlan/#:~:text=If%20the%20parent,the%20network%20completely) claims that "the `--internal` flag that will completely isolate containers on a network from any communications external to that network," which necessitated this advisory and CVE.

Moby Race Condition vulnerability
moby v25.0.5 is affected by a Race Condition in builder/builder-next/adapters/snapshot/layer.go. The vulnerability could be used to trigger concurrent builds that call the EnsureLayer function resulting in resource leaks/exhaustion.

Moby Race Condition vulnerability
moby v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to trigger multiple concurrent write operations resulting in data corruption or application crashes.

IPv6 enabled on IPv4-only network interfaces
In 26.0.0 and 26.0.1, IPv6 is not disabled on network interfaces, including those belonging to networks where `--ipv6=false`.

### Impact

A container with an `ipvlan` or `macvlan` interface will normally be configured to share an external network link with the host machine. Because of this direct access, with IPv6 enabled:

- Containers may be able to communicate with other hosts on the local network over link-local IPv6 addresses.
- If router advertisements are being broadcast over the local network, containers may get SLAAC-assigned addresses.
- The interface  will be a member of IPv6 multicast groups.

This means interfaces in IPv4-only networks present an unexpectedly and unnecessarily increased attack surface.

A container with an unexpected IPv6 address can do anything a container configured with an IPv6 address can do. That is, listen for connections on its IPv6 address, open connections to other nodes on the network over IPv6, or attempt a DoS attack by flooding packets from its IPv6 address. This has CVSS score AV:L/AC:H/PR:N/UI:R/S:C/C:N/I:N/A:L (2.7).

Because the container may not be constrained by an IPv6 firewall, there is increased potential for data exfiltration from the container. This has CVSS score AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N (4.7).

A remote attacker could send malicious Router Advertisements to divert traffic to itself, a black-hole, or another device. The same attack is possible today for IPv4 macvlan/ipvlan endpoints with ARP spoofing, TLS is commonly used by Internet APIs to mitigate this risk. The presence of an IPv6 route could impact the container's availability by indirectly abusing the behaviour of software which behaves poorly in a dual-stack environment. For example, it could resolve a name to a DNS AAAA record and keep trying to connect over IPv6 without ever falling back to IPv4, potentially denying service to the container. This has CVSS score AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H (4.5).

### Patches

The issue is patched in 26.0.2.

### Workarounds

To completely disable IPv6 in a container, use `--sysctl=net.ipv6.conf.all.disable_ipv6=1` in the `docker create` or `docker run` command. Or, in the service configuration of a `compose` file, the equivalent:

```
        sysctls:
            - net.ipv6.conf.all.disable_ipv6=1
```

### References

- sysctl configuration using `docker run`:
  - https://docs.docker.com/reference/cli/docker/container/run/#sysctl
- sysctl configuration using `docker compose`:
  - https://docs.docker.com/compose/compose-file/compose-file-v3/#sysctls

Classic builder cache poisoning
The classic builder cache system is prone to cache poisoning if the image is built `FROM scratch`.
Also, changes to some instructions (most important being `HEALTHCHECK` and `ONBUILD`) would not cause a cache miss.


An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps.

For example, an attacker could create an image that is considered as a valid cache candidate for:
```
FROM scratch
MAINTAINER Pawel
```

when in fact the malicious image used as a cache would be an image built from a different Dockerfile.

In the second case, the attacker could for example substitute a different `HEALTCHECK` command.


### Impact

23.0+ users are only affected if they explicitly opted out of Buildkit (`DOCKER_BUILDKIT=0` environment variable) or are using the `/build` API endpoint (which uses the classic builder by default).

All users on versions older than 23.0 could be impacted. An example could be a CI with a shared cache, or just a regular Docker user pulling a malicious image due to misspelling/typosquatting.

Image build API endpoint (`/build`) and `ImageBuild` function from `github.com/docker/docker/client` is also affected as it the uses classic builder by default. 


### Patches

Patches are included in Moby releases:

- v25.0.2
- v24.0.9
- v23.0.10

### Workarounds

- Use `--no-cache` or use Buildkit if possible (`DOCKER_BUILDKIT=1`, it's default on 23.0+ assuming that the buildx plugin is installed).
- Use `Version = types.BuilderBuildKit` or `NoCache = true` in `ImageBuildOptions` for `ImageBuild` call.