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-2021-25742: Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces #7837
Comments
|
@cjcullen: This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the The 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. |
|
/assign |
|
I don't know if it related but our ingresses stopped to work 2 hours ago (more or less) with: And the service was not in place at all, just the GKE - 1.19.13-gke.1200 |
|
@paolomainardi I don't think so. The CVE says, that non admin users who create or update ingress nginx instances, could possibly all secrets of the cluster. Sound more like a bug TBH. Feel free to raise an issue :) |
|
@iamNoah1 yes i guess so, but you know the timing was so close that i thought it was worth sharing, thanks :) |
|
Might be obvious to others but there's an actually FIX coming right ? The final fix isn't removing a feature ? |
|
Hi, I would appreciate some clarification. Is the ability to retrieve "secrets across all namespaces" a consequence of "Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token"? In other words, the vulnerability allows a user to access the serviceaccount token and as a result of that the service token can then be used to access any resource that the token is allowed? |
|
@dezmodue I had a look at this issue today, and there's definitely an attack path that gets the ingress-nginx service account token, which has list rights on secrets at a cluster level (so allowing for all secret values to be retrieved). There may be other attack paths as well, but that is one of them. |
|
Can you kindly check if disabling snippets helps.
Thanks,
; Long
…On Fri, 22 Oct, 2021, 8:03 PM Rory McCune, ***@***.***> wrote:
@dezmodue <https://github.com/dezmodue> I had a look at this issue today,
and there's definitely an attack path that gets the ingress-nginx service
account token, which has list rights on secrets at a cluster level (so
allowing for all secret values to be retrieved). There may be other attack
paths as well, but that is one of them.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#7837 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGZVWXORRCOBXHFRRBPJJDUIFY4DANCNFSM5GOP5DSA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Hi @raesene, thanks for your reply. In some setups the ingress controller is "namespaced" and the service account is only allowed to get secrets that belong to the same namespace. The users with access to the namespace are the ones managing the ingress controller and have access to the token already so this seems to be a non issue in this scenario. |
|
Well Kubescape already came out with a control that will detect whether your cluster has this vulnerability |
|
@dezmodue So for the case I found, I think so. Basically the snippets facility seems to provide effectively full control over the nginx config and access to the ingress-controller container, so if those are effectively not issues (i.e. all the resources owned by the ingress controller are already owned by the individual teams) then it doesn't seem like there'd be a big impact (AFAIK and I'm not one of the devs, just a curious security person :) ) |
|
What is the actual vuln.?
That link is to this issue, i.e., it links to itself "for more details". |
|
Hi folks, I'm gonna try to answer all your questions here, and we are also scheduling an office hours to explain about this vulnerability and why you should take care of it.:
Correct. If you trust users with access to the ingress object there is no big deal. The problem here is, if you share a cluster, and some user uses the custom annotation to add random code that can be used to exfiltrate secrets (or do other stuff).
This is the actual vuln. You can use custom snippets to run arbitrary code and exfiltrate secrets from the container running ingress nginx.
|
@rikatz I should have been more precise, I guess. I surmised that it was probably the case that some sort of code execution was occurring (others are guessing that that is used to access the service account credentials, and from there, "it's obvious" suffices). My understanding of snippets is that they're nginx configurations; how is it that I can run code from an nginx configuration? (Does nginx have a directive that amounts to an |
With
It's not split from the original questions, I guess this was his answer :p |
|
@roy-work I prefer in this case not enter in details, just bare in mind that NGINX does not have this directive, but we use some other modules that may allow the vulnerability written here :) |
|
On each sync the blocklist is logged with error level. Shouldn't it have info level and a bit clearer message like
|
|
As this is now publicly available, seems like the technical details in the HackerOne report for this issue could be useful for people looking to design/test mitigations https://hackerone.com/reports/1249583 |
|
rather than opening a new issue, i'm going to use this one to mention an ambiguity in the documentation. this pr adds documentation for "suggested" strings that should be blocked in it is not clear whether the last character that should be blocked is a maybe the documentation intends to list all the troublesome strings in which case it may be better to do: or or with the double quotes included in the code comment, it seems like this should be a copy-paste-able string for my yaml config. but, of course, the yaml parser will bawk at the unterminated string: |
|
Hi All, Do we need to update configmap, even if nginx version is 1.19.4 As I’m expecting, by default below parameter will be false in nginx 1.19.4 allow-snippet-annotations:“false” appreciate your inputs |
|
We were recently notified about this CVE. I see this seems to be fixed in v1.2.0. |
|
@foxylion unfortunately not. You can still block the usage of *snippets, but there;s another vulnerability in main ingress object that should be dealt with. What version are you? I'm closing this issue as it's already fixed in the latest version, and we are planning to deprecate the legacy version so I highly recommend migrating to ingress v1.X Thanks! |
|
@rikatz: 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. |


Issue Details
A security issue was discovered in ingress-nginx where a user that can create or update ingress objects can use the custom snippets feature to obtain all secrets in the cluster.
This issue has been rated High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L), and assigned CVE-2021-25742.
Affected Components and Configurations
This bug affects ingress-nginx.
Multitenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.
Affected Versions with no mitigation
Versions allowing mitigation
This issue cannot be fixed solely by upgrading ingress-nginx. It can be mitigated in the following versions:
Mitigation
To mitigate this vulnerability:
Upgrade to a version that allows mitigation, (>= v0.49.1 or >= v1.0.1)
Set allow-snippet-annotations to false in your ingress-nginx ConfigMap based on how you deploy ingress-nginx:
Static Deploy Files
Edit the ConfigMap for ingress-nginx after deployment:
Add directive:
More information on the ConfigMap here
Deploying Via Helm
Set
controller.allowSnippetAnnotationstofalsein the Values.yaml or add the directive to the helm deploy:https://github.com/kubernetes/ingress-nginx/blob/controller-v1.0.1/charts/ingress-nginx/values.yaml#L76
Detection
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io
Additional Details
See ingress-nginx Issue #7837 for more details.
Acknowledgements
This vulnerability was reported by Mitch Hulscher.
Thank You,
CJ Cullen on behalf of the Kubernetes Security Response Committee
The text was updated successfully, but these errors were encountered: