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
Comments
|
@micahhausler: The label(s) In response to this:
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. |
|
/sig api-machinery instrumentation |
|
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
|
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 |
|
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. |
|
/remove-sig instrumentation |
|
/triage accepted |
|
Hi! Will this CVE ever fixed somehow? Our security scan reports the |
|
@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. |
|
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 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. |
|
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 |
|
@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. |
|
@lavalamp Thank you.I hadn't considered this situation. |
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
--profilingis 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
The text was updated successfully, but these errors were encountered: