[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 1 Jun 2020 10:06:58 -0600
From: Joel Smith <joelsmith@...hat.com>
To: kubernetes-security-announce@...glegroups.com,
kubernetes-announce@...glegroups.com, kubernetes-dev@...glegroups.com,
kubernetes-security-discuss@...glegroups.com,
oss-security@...ts.openwall.com, kubernetes+announcements@...coursemail.com
Subject: Kubernetes: IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router
advertisements
Hi Kubernetes Community,
A container networking vulnerability has been disclosed.
Issue details:
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
Affected components and versions:
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:
* kubelet v1.18.0-v1.18.3
* kubelet v1.17.0-v1.17.6
* kubelet < v1.16.11
A cluster having an affected kubernetes-cni package installed is only
affected if configured to use it.
Fixed versions:
The following packages will bundle fixed versions of the
containernetworking CNI plugins that were formerly installed via the
kubernetes-cni package.
* kubelet v1.18.4
* kubelet v1.17.7
* kubelet v1.16.11
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
<https://github.com/containernetworking/plugins/releases/tag/v0.8.6>.
The patch versions are expected to be released on June 17th
<https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md#timelines>,
subject to change.
Third-party components and versions:
Many container networking implementations are affected, including:
* CNI Plugins maintained by the containernetworking team
<https://github.com/containernetworking/plugins>, prior to version
0.8.6 (CVE-2020-10749)
* 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
https://github.com/docker/docker-ce/releases/v19.03.11) (CVE-2020-13401)
* Weave Net, prior to version 2.6.3
It is believed that the following are not affected:
* Cilium
* Juniper Contrail Networking
* OpenShift SDN
* OVN-Kubernetes
* Tungsten Fabric
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.
Affected configurations:
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.
Vulnerability impact:
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.
Mitigations:
* Setting the host default to reject router advertisements should
prevent attacks from succeeding, but may break legitimate traffic,
depending upon the networking implementation and the network where
the cluster is running. To change this setting, set the sysctl
net.ipv6.conf.all.accept_ra to 0.
* Using TLS with proper certificate validation
* Disallowing CAP_NET_RAW for untrusted workloads or users. For
example, a Pod Security Policy with a RequiredDropCapabilities that
includes NET_RAW will prevent this attack for controlled workloads.
Detection:
* The IPv6 routing table on nodes will show any attacker-created
entries. For example, a host with IPv6 disabled might show no
default route when running ip -6 route but the same host with an
attack in progress might show an updated default route or a route to
the target address(es). Any IPv6 route with a destination interface
of a host-side container network interface should be investigated.
* The host-side of a container network interface may show additional
configured IPv6 addresses after receiving a rogue RA packet. For
example, given a host-side interface of cbr0 which might normally
have no IPv6 address, a dynamic-configured address on the interface
may signal an attack in progress. Use this command to view interface
addresses: ip a show dynamic cbr0
Acknowledgements:
Thanks to Etienne Champetier for disclosing this vulnerability.
Additional Details:
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
