If you see 400 Bad Request, that means this pod has access to the admission controller.
How easy would it be to find an avenue to make a request to the admission controller for anything running on your k8s cluster? (maybe your service takes any kind of URL and makes a request on your server...there's infinite possibilities of exploiting this.)
I am rethinking my choice in using ingress-nginx entirely, perhaps it's time to find a simpler solution that has more secure defaults.
These seems overblown since because configuring your ingress controllers and annotating your pods is like "I copy and pasted bash | sudo" but controllers in k8s are a totally insane pattern so I guess any of them could steal/do a lot of evil, really.
It's "overblown" because of these dumb CVSS scores that get attached to vulnerabilities as if they had any meaning at all (they do not). By itself, it's just a marginally interesting semi-remote vuln, effectively a privesc within a K8s deployment.
This is literally true, it is the worst conceivable vulnerability, total access to your k8s cluster by hitting a URL, how about a 10 instead of 9.8, these comments are wild.
I certainly stopped what I was doing to go check. This is a badly overblown emergency which degrades everyone’s ability to properly respond to actual emergencies.
Yeah, and there have been a lot of these lately. The more nothing-burger 9.8+ severity vulnerabilities there are, the less space there is for communicating "this is actually a severe vulnerability and you need to pay attention".
Heartbleed was a 7.5. The entire security community is constantly shouting "RED ALERT, THIS IS A MUCH MUCH WORSE VULNERABILITY THAN HEARTBLEED" and they're all just non-issues.
That's a CVSS issue. Heartbleed only affected Confidentiality, and CVSS rates scores on a triad of Confidentiality, Integrity, and Availability. RCE affects all three.
That's exactly what I'm complaining about, yes. Nothing burgers get 9.8, while earth shattering vulnerabilities get 7.5 using the scoring system that the security community uses to describe "severity".
The Helm chart has not been updated yet, but it looks like you can use the new container images by manually specifying the updated image tag in the values file:
No evidence, but the fact that the "IngressNightmare" PR piece was announced before there were even PRs created to fix this smells like the team at Wiz leaked this before it was really ready.
Whether the scores are legit or not, the fact that this was such a botched disclosure process is not a good look for the Kubernetes project, of which this is a part.
Edit: According to [1], the team at Wiz show a responsible disclosure timeline. Seems like the Kubernetes project's process didn't work so well. If Wiz is accurately reporting what happened in their blog, these fixes (or the plan for them) was available a month ago, despite seemingly not having working PRs until today, after the security announcement?
Again, I really appreciate the work of the team to ship this, but this isn't a good look for the Kubernetes project itself.
> Multiple issues have been discovered in ingress-nginx that can result in arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)
Beyond that, it could likely be used to sniff out client secrets from other connections as well if the attacker is sophisticated enough.
