The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.6 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
43222A9D-6D48-490F-8120-349DCE1C1218
1.15.0
1.6.0
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
FE1EA8C5-2EF4-4462-B693-FE20B3DF75C6
1.16.13
1.16.0
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
CC1FA454-87A3-480C-BB5E-A23086E2EA99
1.17.9
1.17.0
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
3E4009BA-8220-4B8E-8B4B-1ADA1680DD70
1.18.6
1.18.0
OR
CVSS Rating: Medium (6.4) [CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H)

If an attacker is able to intercept certain requests to the Kubelet, they can send a redirect response that may be followed by a client using the credentials from the original request. This can lead to compromise of other nodes.

If multiple clusters share the same certificate authority trusted by the client, and the same authentication credentials, this vulnerability may allow an attacker to redirect the client to another cluster. In this configuration, this vulnerability should be considered **High** severity.

### Am I vulnerable?

You are only affected by this vulnerability if you treat the node as a security boundary, or if clusters share certificate authorities and authentication credentials.

Note that this vulnerability requires an attacker to first compromise a node through separate means.

#### Affected Versions

- kube-apiserver v1.18.0-1.18.5
- kube-apiserver v1.17.0-1.17.8
- kube-apiserver v1.16.0-1.16.12
- all kube-apiserver versions prior to v1.16.0

### How do I mitigate this vulnerability?

To mitigate this vulnerability you must upgrade the kube-apiserver to a patched version.

#### Fixed Versions

- kube-apiserver master - fixed by https://github.com/kubernetes/kubernetes/pull/92941
- kube-apiserver v1.18.6 - fixed by https://github.com/kubernetes/kubernetes/pull/92969
- kube-apiserver v1.17.9 - fixed by https://github.com/kubernetes/kubernetes/pull/92970
- kube-apiserver v1.16.13 - fixed by https://github.com/kubernetes/kubernetes/pull/92971


**Fix impact:** Proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code may be broken by this patch.

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster

### Detection

Upgrade requests should never respond with a redirect. If any of the following requests have a response code in the 300-399 range, it may be evidence of exploitation. This information can be found in the Kubernetes audit logs.

- pods/exec
- pods/attach
- pods/portforward
- any resource: proxy

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

#### Acknowledgements

This vulnerability was reported by Wouter ter Maat of Offensi, via the Kubernetes bug bounty.

/area security
/kind bug
/committee product-security
/sig api-machinery
/area apiserver
CVE-2020-8559: Privilege escalation from compromised node to cluster
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : CVE-2020-8559: Privilege escalation from compromised node to cluster
Issue date:

--- start body ---
CVSS Rating: Medium (6.4) [CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H)

If an attacker is able to intercept certain requests to the Kubelet, they can send a redirect response that may be followed by a client using the credentials from the original request. This can lead to compromise of other nodes.

If multiple clusters share the same certificate authority trusted by the client, and the same authentication credentials, this vulnerability may allow an attacker to redirect the client to another cluster. In this configuration, this vulnerability should be considered **High** severity.

### Am I vulnerable?

You are only affected by this vulnerability if you treat the node as a security boundary, or if clusters share certificate authorities and authentication credentials.

Note that this vulnerability requires an attacker to first compromise a node through separate means.

#### Affected Versions

- kube-apiserver v1.18.0-1.18.5
- kube-apiserver v1.17.0-1.17.8
- kube-apiserver v1.16.0-1.16.12
- all kube-apiserver versions prior to v1.16.0

### How do I mitigate this vulnerability?

To mitigate this vulnerability you must upgrade the kube-apiserver to a patched version.

#### Fixed Versions

- kube-apiserver master - fixed by https://github.com/kubernetes/kubernetes/pull/92941
- kube-apiserver v1.18.6 - fixed by https://github.com/kubernetes/kubernetes/pull/92969
- kube-apiserver v1.17.9 - fixed by https://github.com/kubernetes/kubernetes/pull/92970
- kube-apiserver v1.16.13 - fixed by https://github.com/kubernetes/kubernetes/pull/92971


**Fix impact:** Proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code may be broken by this patch.

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster

### Detection

Upgrade requests should never respond with a redirect. If any of the following requests have a response code in the 300-399 range, it may be evidence of exploitation. This information can be found in the Kubernetes audit logs.

- pods/exec
- pods/attach
- pods/portforward
- any resource: proxy

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

#### Acknowledgements

This vulnerability was reported by Wouter ter Maat of Offensi, via the Kubernetes bug bounty.

/area security
/kind bug
/committee product-security
/sig api-machinery
/area apiserver
--- end body ---

comments :
--- start comments ---

--- end comments ---