Hi Kubernetes Community,
A container networking vulnerability has been disclosed.
A cluster configured to use an affected container networking
implementation is susceptible to man-in-the-middle (MitM) attacks.
By sending “rogue” router advertisements, a malicious container
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.
This vulnerability has been given a severity of Medium with a
score of 6.0 https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L
Kubernetes itself is not vulnerable. A Kubernetes cluster using
an affected networking implementation is vulnerable.
Binary releases of the kubelet installed from upstream Kubernetes
Community repositories hosted at https://packages.cloud.google.com/
may have also installed the kubernetes-cni package
containing the containernetworking CNI plugins, which are affected
by CVE-2020-10749.
The following official kubelet package versions have an affected
kubernetes-cni package as a dependency:
A cluster having an affected kubernetes-cni package
installed is only affected if configured to use it.
The following packages will bundle fixed versions of the
containernetworking CNI plugins that were formerly installed via
the kubernetes-cni package.
Because these versions are not yet available, cluster
administrators using packages from the Kubernetes repositories may
choose to manually upgrade CNI plugins by retrieving the relevant
arch tarball from the containernetworking/plugins v0.8.6
release. The patch versions are expected
to be released on June 17th, subject to change.
Many container networking implementations are affected,
including:
It is believed that the following are not affected:
Information about the vulnerability status of any plugins or
implementations not listed above is currently unavailable. Please
contact the provider directly with questions about their
implementation.
Clusters using an affected networking implementation and allowing
workloads to run with CAP_NET_RAW privileges. The
default Kubernetes security context runs workloads with a
capabilities bounding set that includes CAP_NET_RAW.
A user able to create containers with CAP_NET_RAW
privileges on an affected cluster can intercept traffic from other
containers on the host or from the host itself.
Thanks to Etienne Champetier for disclosing this vulnerability.
See the GitHub issue at https://github.com/kubernetes/kubernetes/issues/91507 for more information.
Thank you,
Joel Smith, on behalf of the Kubernetes Product Security Committee