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-8561: Webhook redirect in kube-apiserver #104720

Open
micahhausler opened this issue Sep 1, 2021 · 13 comments
Open

CVE-2020-8561: Webhook redirect in kube-apiserver #104720

micahhausler opened this issue Sep 1, 2021 · 13 comments
Labels
area/security 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 Sep 1, 2021

A security issue was discovered in Kubernetes where actors that control the responses of MutatingWebhookConfiguration or ValidatingWebhookConfiguration requests are able to redirect kube-apiserver requests to private networks of the apiserver. If that user can view kube-apiserver logs when the log level is set to 10, they can view the redirected responses and headers in the logs.

This issue has been rated Medium (https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) (4.1), and assigned CVE-2020-8561

Am I vulnerable?

You may be vulnerable if --profiling is enabled on the kube-apiserver and actors who control a validating or mutating webhook can access the kube-apiserver process logs.

Affected Versions

This issue affects all known versions of kube-apiserver.

How do I mitigate this vulnerability?

This issue can be mitigated by not allowing kube-apiserver access to sensitive resources or networks, or to reduce the “-v” flag value to less than 10 and set the “--profiling” flag value to “false” (default value is “true”). Setting the profiling flag to “false” prevents users from dynamically modifying the kube-apiserver log level, and the flag value Webhook requests may still be redirected to private networks with a log level less than 10, but the response body will not be logged.

Fixed Versions

There is no fix for this issue at this time.

Detection

Examining kube-apiserver log responses is the only known method of detection for this issue.

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

Acknowledgements

This vulnerability was reported by QiQi Xu

/triage accepted
/lifecycle frozen
/area security
/kind bug
/committee security-response

@micahhausler micahhausler added the kind/bug Categorizes issue or PR as related to a bug. label Sep 1, 2021
@k8s-ci-robot k8s-ci-robot added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Sep 1, 2021
@k8s-ci-robot
Copy link
Contributor

@micahhausler: The label(s) committee/security-response cannot be applied, because the repository doesn't have them.

In response to this:

/triage accepted
/lifecycle frozen
/area security
/kind bug
/committee security-response

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. area/security needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Sep 1, 2021
@micahhausler micahhausler changed the title TITLE: PLACEHOLDER ISSUE PLACEHOLDER ISSUE Sep 1, 2021
@micahhausler micahhausler changed the title PLACEHOLDER ISSUE CVE-2020-8561: Webhook redirect in kube-apiserver Sep 15, 2021
@neolit123
Copy link
Member

/sig api-machinery instrumentation

@k8s-ci-robot k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/instrumentation Categorizes an issue or PR as relevant to SIG Instrumentation. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Sep 20, 2021
@k8s-triage-robot
Copy link

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

  • Confirm that this issue is still relevant with /triage accepted (org members only)
  • Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

@k8s-ci-robot k8s-ci-robot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. and removed triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Feb 8, 2023
@cici37
Copy link
Contributor

cici37 commented Feb 9, 2023

Hi @micahhausler , We are at sig apimachinery bugsrub meeting and this comes up. We are wondering if this has been handled properly or if there is any action needed from apimachinery? Thank you

@lavalamp
Copy link
Member

We need to document better how to use egresses to block this kind of attack. I don't think there will be any code changes since there are already configuration workarounds and only certain clusters match the threat model.

@logicalhan
Copy link
Contributor

/remove-sig instrumentation

@k8s-ci-robot k8s-ci-robot removed the sig/instrumentation Categorizes an issue or PR as relevant to SIG Instrumentation. label Feb 23, 2023
@cici37
Copy link
Contributor

cici37 commented Feb 23, 2023

/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 Feb 23, 2023
@szombi
Copy link

szombi commented Apr 21, 2023

Hi! Will this CVE ever fixed somehow? Our security scan reports the golang/k8s.io/apiserver@v0.25.0 import vulenrable because of this issue.

@dims
Copy link
Member

dims commented Apr 21, 2023

@szombi please use the steps outlined to mitigate if you are worried about this CVE. once you have done that, ignore this CVE in your scanner.

@lavalamp
Copy link
Member

The nature of this CVE is "it's possible to configure apiserver wrong for your situation". There's not really a code fix to be made because we don't want to forbid things that are fine for many people.

The threat model here is "actors who run mutating or validating webhooks". If the people running your mutating or validating webhooks are malicious, my best guess is that this CVE is far from the best way for them to do harm.

That said, you should absolutely not leave --profiling on for production clusters unless you're actively troubleshooting apiserver. And it's very unlikely that you have --v set higher than 2, at 10 it will destroy your log collection system for sure. So the mitigation steps are good to follow in any case.

If you want to fix all possible problems of this class, you can configure egresses to make sure apiserver egress traffic can't go to the wrong place. Unfortunately the only guide out there describes only how to use it with konnectivity to get traffic to cluster nodes. The feature should also be usable without konnectivity, to force traffic to go only to the kind of place apiserver thinks it should go. You will need some sort of proxy, I believe envoy should work but I have not tested it.

@yy158775
Copy link

I can't understand the threat model of CVE-2022-3172. Aggregated API servers are a trusted part of the Kubernetes control plane, and configuring them is a privileged administrative operation. If the people have such privilege,they can do more harm without this CVE.

So I think CVE-2022-3172 is meaningless because it's threat model is so unrealistic. @lavalamp

@lavalamp
Copy link
Member

@yy158775 the CVE you linked to is not the CVE that this issue is about. I agree that installing untrusted aggregated apiservers is a really bad idea. However, consider the possibility of installing a standard aggregated apiserver which has compiled in a back-door'd dependency.

@yy158775
Copy link

@lavalamp Thank you.I hadn't considered this situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security 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

10 participants