-
Notifications
You must be signed in to change notification settings - Fork 40.6k
CVE-2021-25740: Endpoint & EndpointSlice permissions allow cross-Namespace forwarding #103675
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
Comments
The |
CVE-2021-25740 atack is possible to expose backend IPs to ExternalName Services kubernetes/kubernetes#103675
CVE-2021-25740 atack is possible to expose backend IPs to ExternalName Services kubernetes/kubernetes#103675
appended .txt suffix and attached it to the description |
… teeLoppback() fix: CVE-2021-25740 kubernetes/kubernetes#103675 allowed externalNames Signed-off-by: Sandor Szücs <sandor.szuecs@zalando.de>
I'm sorry, I misunderstood that the |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Hi, could anyony explain whether or not this has been fixed (and in what version)? We are currently using GKE (v1.21.11 and v1.22.8) |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. 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. |
Getting closed out by the triage bot is a kinda unceremonious death, but this issue should have been closed a while back with the work done to remove Endpoint & EndpointSlice permissions from the default roles, and docs changes to highlight the risk. |
Although this issue was closed, please notice that the Endpoint & EndpointSlice permission won't be deleted automactically if upgrading K8s from an impacted version. Here are some tips for this situation. Please correct me if anything wrong. I suggest to remove the Endpoint & EndpointSlice permission only instead of directly using the yaml above because it will delete more permissions on the new K8s version. And it is better to set Commands for reference:
|
Is this is the pr (103703) that fixed this? Looks like this went into 1.22.0 |
@RyanStan this is the most relevant PR (also merged to 1.22): #103704. The other PR reverts a change that was merged in the 1.22 release cycle but reverted. As the issue above states, that patch is only effective for new 1.22+ clusters, others will want to run the manual mitigation steps described above. |
Hi, when using vcluster, this RBAC is needed (see loft-sh/vcluster#1465). We cannot deploy vcluster, which is a really useful tool to deploy components that needs cluster-wide privilege for CRDs, in an shared environment Kubernetes. I am thinking of alternative on how to mitigate this CVE while find a way to deploy vcluster.Since Ingresses are a bit deprecated in favor of Gateway API (which is now GA and integrated in OpenShift). Does this CVE impacts Gateway API? Maybe if we disable Ingresses and only enable Gateway in our shared Kubernetes, if that CVE is not relevant in this configuration, then our admin could give Endpoints privilege again... |
A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack.
This issue has been rated Low severity (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), and assigned CVE-2021-25740.
Am I vulnerable?
If a potential attacker can create or edit Endpoints or EndpointSlices in the Kubernetes API, they can potentially direct a LoadBalancer or Ingress implementation to expose backend IPs the attacker should not have access to.
Importantly, if the target’s NetworkPolicy already trusts the Load Balancer or Ingress implementation, NetworkPolicy can not be used to prevent exposure from other namespaces, potentially bypassing any security controls such as LoadBalancerSourceRanges.
This issue is a design flaw that cannot be fully mitigated without user-facing changes. With this public announcement, we can begin conversations about a long-term fix.
Affected Versions
All Kubernetes versions are affected.
How do I mitigate this vulnerability?
There is no patch for this issue, and it can currently only be mitigated by restricting access to the vulnerable features. To mitigate the exposure, we recommend restricting write access to Endpoints and EndpointSlices by updating the system:aggregate-to-edit role using the attached file. This will remove write access to Endpoints from the admin and edit roles:
Note: This will prevent new versions of Kubernetes from reconciling new default permissions to this role. No new default permissions have been added to this role since v1.14.0, but we recommend you remove the autoupdate=false annotation as soon as a fix or other mitigation is possible.
For use-cases that need to edit these resources, we recommend creating a new purpose-built Role with the desired permissions, and using it only for those cases.
Detection
Services with an empty selector rely on custom endpoints and are vulnerable to the attack described above. We recommend manually auditing any such usage. The following kubectl command will list all Services in a cluster with their selector:
Note: Some Services without selectors specified may have their Endpoints managed by other controllers or tools. For example, endpoints for the default/kubernetes Service are managed by the Kubernetes API Server.
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io
Additional Advisory
A similar attack is possible using Ingress implementations that support forwarding to ExternalName Services. This can be used to forward to Services in other namespaces or, in some cases, sensitive endpoints within the Ingress implementation. If you are using the Ingress API, we recommend confirming that the implementation you’re using either does not support forwarding to ExternalName Services or supports disabling the functionality.
Additional Details
See the GitHub issue for more updates: #103675
Thank You,
Rob Scott on behalf of Kubernetes SIG Network and CJ Cullen on behalf of the Kubernetes Product Security Committee
The text was updated successfully, but these errors were encountered: