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

CVE-2020-8562: Bypass of Kubernetes API Server proxy TOCTOU #101493

Open
micahhausler opened this issue Apr 26, 2021 · 6 comments
Open

CVE-2020-8562: Bypass of Kubernetes API Server proxy TOCTOU #101493

micahhausler opened this issue Apr 26, 2021 · 6 comments
Labels
area/security committee/security-response Denotes an issue or PR intended to be handled by the product security committee. kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@micahhausler
Copy link
Member

micahhausler commented Apr 26, 2021

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

A security issue was discovered in Kubernetes where an authorized user may be able to access private networks on the Kubernetes control plane components. Kubernetes clusters are only affected if an untrusted user can create or modify Node objects and proxy to them, or an untrusted user can create or modify StorageClass objects and access KubeControllerManager logs.

This issue has been rated Low (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N) and assigned CVE-2020-8562.

As mitigations to a report from 2019 and CVE-2020-8555, Kubernetes attempts to prevent proxied connections from accessing link-local or localhost networks when making user-driven connections to Services, Pods, Nodes, or StorageClass service providers. As part of this mitigation Kubernetes does a DNS name resolution check and validates that response IPs are not in the link-local (169.254.0.0/16) or localhost (127.0.0.0/8) range. Kubernetes then performs a second DNS resolution without validation for the actual connection. If a non-standard DNS server returns different non-cached responses, a user may be able to bypass the proxy IP restriction and access private networks on the control plane.

Affected Versions:

Kubernetes <= v1.21.0
Kubernetes <= v1.20.6
Kubernetes <= v1.19.10
Kubernetes <= v1.18.18

Fixed Versions

There is no fix for this issue at this time.

Mitigations

If this issue affects your clusters’ control planes, you can use dnsmasq for name resolution and configure the min-cache-ttl and neg-ttl parameters to a low non-zero value to enforce cached replies for proxied connections.

Detection

This issue is not known to be directly detectable, but proxied calls will appear in the Kubernetes API Audit log. Kubernetes will respond with “address not allowed” when the validation successfully prevents a connection.

Acknowledgements

This vulnerability was reported by Javier Provecho (Telefonica).

/area security
/kind bug
/committee product-security
/triage accepted

@micahhausler micahhausler added the kind/bug Categorizes issue or PR as related to a bug. label Apr 26, 2021
@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. area/security committee/security-response Denotes an issue or PR intended to be handled by the product security committee. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Apr 26, 2021
@micahhausler micahhausler changed the title PLACEHOLDER ISSUE CVE-2020-8562: Bypass of Kubernetes API Server proxy TOCTOU May 4, 2021
@cjcullen
Copy link
Member

cjcullen commented May 4, 2021

One potential way to fix this might be to pass the resolved IP through to the second call, so we only ever use an IP that we've verified "is proxyable." I haven't tested it, but something like this: cjcullen@8f648b7

@cjcullen cjcullen added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label May 6, 2021
@caesarxuchao
Copy link
Member

/cc @lavalamp @deads2k
/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 6, 2021
@OS-WS
Copy link

OS-WS commented Jul 6, 2021

Hi,
Was this issue ever addressed/ fixed?

Thanks in advance!

@lavalamp
Copy link
Member

lavalamp commented Jul 7, 2021

We have not, changes like CJ's (above) are invasive and no one has had time to completely work one out, given the perceived lack of severity. Proper configuration / use of the egress settings may address this anyway-- wasn't an option when this was discovered but may be now.

@dennis-benzinger-hybris

I assume this bug still exists in 1.22, yes?

The initial description doesn't list it as an affected version but I guess that's just because 1.22 didn't exist when the bug was reported.

@dennis-benzinger-hybris
Copy link

dennis-benzinger-hybris commented Nov 3, 2022

@lavalamp, could you maybe answer my question above about the affected Kubernetes versions? Thanks!

And also if the bug exists in all versions after 1.22 😉.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security committee/security-response Denotes an issue or PR intended to be handled by the product security committee. kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

7 participants