Kubernetes clusters configured to use certain container networking
implementations (CNIs) are susceptible to man-in-the-middle (MitM) attacks, the Kubernetes Product Security Committee has warned.
The vulnerability affects clusters running a “default Kubernetes security context”: i.e. workloads running with CAP_NET_RAW privileges.
There’s no upstream fix till June 17, so users may want to mitigate or take some manual steps to individually update the CNI plugins that are the culprit — these have found their way into upstream kubelet binary releases.
What’s this Kubernetes Bug Do?
The container networking vulnerability can be exploited by sending rogue router advertisements: this lets a malicious container reconfigure the host to redirect its IPv6 traffic to an attacker-controlled container.
(n.b. “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.”)
Where’s the Bug?
The bug is not in Kubernetes per se, but in various CNI plugins.
These have been bundled into various upstream binary kubelet (the lowest level component in Kubernetes) releases, including those installed from upstream Kubernetes community repositories hosted at https://packages.cloud.google.com/.
The following official kubelet package versions have a kubernetes-cni package as a dependency that is affected by the vulnerability.
* kubelet v1.18.0-v1.18.3
* kubelet v1.17.0-v1.17.6
* kubelet < v1.16.11
Affected container networking implementations include:
* CNI Plugins maintained by the container networking team
<https://github.com/containernetworking/plugins>, prior to version
* Calico and Calico Enterprise (CVE-2020-13597) Please refer to the
Tigera Advisory TTA-2020-001 at
https://www.projectcalico.org/security-bulletins/ for details
* Docker versions prior to 19.03.11 (see
* Weave Net, prior to version 2.6.3
The vulnerability has a “medium” CVSS score of 6.0, but probably shouldn’t be ignored, considering what can be done with it.
The Kubernetes Product Security Committee suggests the following mitigations: “Setting the host default to reject router advertisements should
prevent attacks from succeeding…”
This “may break legitimate traffic, depending upon the networking implementation and the network where the cluster is running. To change this setting, set the sysctlnet.ipv6.conf.all.accept_ra to 0.”
It also suggests using TLS with proper certificate validation and disallowing CAP_NET_RAW for untrusted workloads or users.
Credit for the find goes to Etienne Champetier.
A more detail analysis of the issue including detection details is here.