[Security Advisory] CVE-2020-8555: Half-Blind SSRF in kube-controller-manager

Hello Kubernetes Community,

There exists a Server Side Request Forgery (SSRF) vulnerability in kube-controller-manager that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master’s host network (such as link-local or loopback services).

This issue has been rated medium (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N), and assigned CVE-2020-8555.

Am I vulnerable?

You may be vulnerable if:

  • You are running a vulnerable version (see below);
  • There are unprotected endpoints normally only visible from the Kubernetes master (including link-local metadata endpoints, unauthenticated services listening on localhost, or other services in the master’s private network); and
  • Untrusted users can create pods with an affected volume type or modify storage classes.

Affected Versions

  • kube-controller-manager v1.18.0
  • kube-controller-manager v1.17.0 - v1.17.4
  • kube-controller-manager v1.16.0 - v1.16.8
  • kube-controller-manager < v1.15.11

The affected volume types are: GlusterFS, Quobyte, StorageFS, ScaleIO

How do I mitigate this vulnerability?

Prior to upgrading, this vulnerability can be mitigated by adding endpoint protections on the master or restricting usage of the vulnerable volume types (for example by constraining usage with a PodSecurityPolicy or third-party admission controller such as Gatekeeper) and restricting StorageClass write permissions through RBAC.

Fixed Versions

The information leak was patched in the following versions:

  • kube-controller-manager v1.18.1+
  • kube-controller-manager v1.17.5+
  • kube-controller-manager v1.16.9+
  • kube-controller-manager v1.15.12+

To upgrade, refer to the documentation: Cluster Management - Kubernetes

Further work to protect against SSRF is underway and will be included in an upcoming patch release (details to follow).

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/91542

Thank You,

Tim Allclair on behalf of the Kubernetes Product Security Committee