Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements #91507

Closed
joelsmith opened this issue May 27, 2020 · 5 comments
Closed
Labels
area/security committee/security-response kind/bug official-cve-feed sig/network

Comments

@joelsmith
Copy link
Contributor

@joelsmith joelsmith commented May 27, 2020

CVSS Rating: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L (6.0 Medium)

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.

Am I vulnerable?

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.

Affected Versions

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.

Third-party components and versions

Many container networking implementations are affected, including:

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.

How do I mitigate this vulnerability?

  • Set the host default to reject router advertisements. This 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.
  • Use TLS with proper certificate validation
  • Disallow 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.

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.19.0+ (master branch #91370)
  • kubelet v1.18.4+ (#91387)
  • kubelet v1.17.7+ (#91386)
  • kubelet v1.16.11+ (#91388)

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.

Additional Details

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

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.

Acknowledgements

This vulnerability was reported by Etienne Champetier (@champtar).

The issue was fixed by Casey Callendrello (@squeed) and maintainers of various container networking implementations. Updates to Kubernetes builds were coordinated by Stephen Augustus (@justaugustus) and Tim Pepper (@tpepper).

/area security
/kind bug
/committee product-security
/sig network

@joelsmith joelsmith added the kind/bug label May 27, 2020
@k8s-ci-robot k8s-ci-robot added the needs-sig label May 27, 2020
@joelsmith joelsmith changed the title Placeholder issue IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements Jun 1, 2020
@k8s-ci-robot k8s-ci-robot added area/security committee/security-response sig/network and removed needs-sig labels Jun 1, 2020
ajayk added a commit to ajayk/amazon-vpc-cni-k8s that referenced this issue Jun 2, 2020
mogren pushed a commit to aws/amazon-vpc-cni-k8s that referenced this issue Jun 2, 2020
@gadinaor
Copy link

@gadinaor gadinaor commented Jun 3, 2020

@joelsmith re: "How do I mitigate this vulnerability?"
the use of TLS partially address the weaknesses this attack introduce.
Denial of service would still be an issue even if TLS is used.

@joelsmith
Copy link
Contributor Author

@joelsmith joelsmith commented Jun 3, 2020

@gadinaor, you are right. When we propose mitigations in these advisories, some may not eliminate the issue. Some may only reduce the severity, as in the case of TLS verification. The best approach is to update the CNI plugin now to a version that is not affected.

@gadinaor
Copy link

@gadinaor gadinaor commented Jun 3, 2020

@joelsmith - thanks - I completely agree with you that updating the vulnerable components is the best approach - I believe that having a note/disclaimer that capture this limitation would help to prevent a false sense of security - I am thinking of Istio users with mTLS enabled that would think that their systems are not vulnerable and skip the update.

@galaktipus
Copy link

@galaktipus galaktipus commented Jun 4, 2020

Any relevant commit for the issue described in CVE-2020-13597?
The commits in this thread just describe a jump of a version.

champtar added a commit to champtar/kubespray that referenced this issue Jun 8, 2020
https://github.com/containernetworking/plugins/releases/tag/v0.8.6
kubernetes/kubernetes#91507

Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
(cherry picked from commit 41b4473)
champtar added a commit to champtar/kubespray that referenced this issue Jun 8, 2020
https://github.com/containernetworking/plugins/releases/tag/v0.8.6
kubernetes/kubernetes#91507

Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
(cherry picked from commit 41b4473)
k8s-ci-robot pushed a commit to kubernetes-sigs/kubespray that referenced this issue Jun 9, 2020
https://github.com/containernetworking/plugins/releases/tag/v0.8.6
kubernetes/kubernetes#91507

Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
(cherry picked from commit 41b4473)
k8s-ci-robot pushed a commit to kubernetes-sigs/kubespray that referenced this issue Jun 9, 2020
https://github.com/containernetworking/plugins/releases/tag/v0.8.6
kubernetes/kubernetes#91507

Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
(cherry picked from commit 41b4473)
k8s-ci-robot pushed a commit to kubernetes/website that referenced this issue Jun 13, 2020
CVE-2020-13401

xref: kubernetes/kubernetes#91507

Signed-off-by: Jintao Zhang <zhangjintao9020@gmail.com>
mogren pushed a commit to mogren/amazon-vpc-cni-k8s that referenced this issue Jun 24, 2020
mogren pushed a commit to mogren/amazon-vpc-cni-k8s that referenced this issue Jun 24, 2020
mogren pushed a commit to aws/amazon-vpc-cni-k8s that referenced this issue Jun 24, 2020
mogren pushed a commit to mogren/amazon-vpc-cni-k8s that referenced this issue Jun 24, 2020
mogren pushed a commit to aws/amazon-vpc-cni-k8s that referenced this issue Jun 24, 2020
@PushkarJ
Copy link
Member

@PushkarJ PushkarJ commented Dec 2, 2021

/label official-cve-feed

(Related to kubernetes/sig-security#1)

@k8s-ci-robot k8s-ci-robot added the official-cve-feed label Dec 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security committee/security-response kind/bug official-cve-feed sig/network
Projects
None yet
Development

No branches or pull requests

5 participants