Shouldn't be fatal: Unable to disable IPv6 router advertisement: open /proc/sys/net/ipv6/conf/docker0/accept_ra: read-only file system

[poige]

• This is a bug report
• This is a feature request
• I searched existing issues before opening this one

Expected behavior

Proceed start

Actual behavior

Aborted start

Steps to reproduce the behavior

I ran Docker in systemd-nspawn "machine" — in particular to avoid cluttering of the netfilter's rule set. Generally it worked until recent update.
Output of docker version:

Client: Docker Engine - Community
 Version:           19.03.11
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        42e35e61f3
 Built:             Mon Jun  1 09:12:22 2020
 OS/Arch:           linux/amd64
 Experimental:      false
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Output of docker info:
— not applicable, since system service is down

The whole error message:

dockerd[…]: failed to start daemon: Error initializing network controller: Error creating default "bridge" network: libnetwork: Unable to disable IPv6 router advertisement: open /proc/sys/net/ipv6/conf/docker0/accept_ra: read-only file system

[Motophan]

#1026 appears to be related

[poige]

#1026 appears to be related

O_o

— Very remotely, because the thing I'm talking about is pretty different in nutshell — recent changes(?) broke ability to start-up Docker's daemon in IPv4 environment. There're no configuration's requests for Docker to run with IPv6 mode enabled.

It started failing only recently and (I repeat) the environment is IPv4 based.

Also when I entered that network namespace manually from the host system and flipped accept_ra to 0 it didn't fix broken Docker's start because its code seems to try (un)setting this knob anyways, treating the failure to do so as a fatal one.

I don't see the point treating it that hard — what's wrong if even accept_ra is 1, how does it hurt Docker at all?

[poige]

Downgrading to docker-ce=5:19.03.10~3-0~ubuntu-bionic resolves the issue, proving it's of a recent change.

[thaJeztah]

Looks related to a CVE that was addressed in 19.03.11; https://docs.docker.com/engine/release-notes/#190311

Disable IPv6 Router Advertisements to prevent address spoofing. CVE-2020-13401

Description

In the Docker default configuration, the container network interface is a virtual ethernet link going to the host (veth interface).
In this configuration, an attacker able to run a process as root in a container can send and receive arbitrary packets to the host using the CAP_NET_RAW capability (present in the default configuration).

If IPv6 is not totally disabled on the host (via ipv6.disable=1 on the kernel cmdline), it will be either unconfigured or configured on some interfaces, but it’s pretty likely that ipv6 forwarding is disabled, that is, /proc/sys/net/ipv6/conf//forwarding == 0. Also by default, /proc/sys/net/ipv6/conf//accept_ra == 1. The combination of these 2 sysctls means that the host accepts router advertisements and configures the IPv6 stack using them.

By sending “rogue” router advertisements from a container, an attacker can reconfigure the host to redirect part or all of the IPv6 traffic of the host to the attacker-controlled container.

Even if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond.
If by chance the host has a vulnerability like last year’s RCE in apt (CVE-2019-3462), the attacker can now escalate to the host.

As CAP_NET_ADMIN is not present by default for Docker containers, the attacker can’t configure the IPs they want to MitM, they can’t use iptables to NAT or REDIRECT the traffic, and they can’t use IP_TRANSPARENT.
The attacker can however still use CAP_NET_RAW and implement a tcp/ip stack in user space.

See kubernetes/kubernetes#91507 for related issues.

@justincormack @arkodg

[justincormack]

yes we should not fail if this file does not exist or is read only cc @arkodg @samuelkarp I think its fine to ignore any failures.

[thaJeztah]

Opened moby/libnetwork#2563

[poige]

Looks related to a CVE that was addressed in 19.03.11

It might be true, the q-n is only why anyone thought it's the Docker's issue?
The same kind of attack is quite possible with bridged KVMs as well, right?
So what now, should QEMU-KVM devs go and shutdown IPv6 completely as well?
I don't think so, it sounds pretty much absurd, as to me.

[tiborvass]

@poige would you be able to test if things are fixed for you by running make on moby/moby#41124 and replacing (dont forget backup) your dockerd binary with ./bundles/binary-daemon/dockerd-dev ?

[poige]

would you be able to test

I will try at least.

[thaJeztah]

Packages for docker 19.03.12 should now be up on download.docker.com, and contain a fix for this. I'll go ahead and close this issue, but feel free to comment if the issue still persists