5 ms·

Multiple vulnerabilities in ingress-Nginx (Score 9.8)

76 points by numbsafari 2y ago

Fizzadar 2y ago
OK it requires access to the pod network. Bad, but not that. Here’s the 9.8: https://github.com/kubernetes/kubernetes/issues/131009 https://github.com/kubernetes/kubernetes/issues/131009
IlikeKitties 2y ago
That's quite a terrifying CVE. > 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.
- deleted 2y ago
  [deleted]
yimby2001 2y ago
“unauthenticated attacker with access to the pod network” /yawn
- deleted 2y ago
  [deleted]
liveoneggs 2y ago
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.
- tptacek 2y ago
  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.
  - mort96 2y ago
    Score 9.8 ought to mean, "this is almost the worst conceivable vulnerability".
    - more_corn 2y ago
      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.
      - mort96 2y ago
        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.
        cjbprime 2y ago
        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.
        mort96 2y ago
        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".
deleted 2y ago
[deleted]
formerly_proven 2y ago
4x “stuff dumped into a configuration file verbatim” 1x “just run the code, CJ”
AcidBurn 2y ago
Resolved in ingress-nginx v1.11.5/v1.12.1 neither of which seem to have been released yet.
- AcidBurn 2y ago
  Looks like the container images for both versions are now available: registry.k8s.io/ingress-nginx/controller:v1.12.1 registry.k8s.io/ingress-nginx/controller:v1.11.5 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: controller: image: tag: "v1.12.1"
  - numbsafari 2y ago
    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. [1] https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...
  - AcidBurn 2y ago
    For the sake of completeness I will also mention that the updated Helm chart is now also available: ingress-nginx: 4.12.1
waltercool 2y ago
[dead]
frereit 2y ago
> January 9, 2025 – Kubernetes proposed a fix for CVE-2025-1097. > January 10, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1097. > January 12, 2025 – Kubernetes proposed a fix for CVE-2025-1974. > January 16, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1974. > January 20, 2025 – Kubernetes proposed a fix for CVE-2025-24513. > January 21, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-24513. Lol, lmao even. [1] [1]: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...
- philipwhiuk 2y ago
  The CVE numbering is interesting.
rcconf 2y ago
I am a little confused about the comment section about this being overblown, it really isn't. Ignore all the comments in this post and fix this ASAP. Here's a simple test: `kubectl exec -it` a pod: curl -k --fail https://ingress-nginx-controller-admission.ingress-nginx.svc.cluster.local https://ingress-nginx-controller-admission.ingress-nginx.svc... 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.

76 points by numbsafari 2y ago

OK it requires access to the pod network. Bad, but not that. Here’s the 9.8: https://github.com/kubernetes/kubernetes/issues/131009 https://github.com/kubernetes/kubernetes/issues/131009

IlikeKitties 2y ago

That's quite a terrifying CVE. > 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.

deleted 2y ago
[deleted]

yimby2001 2y ago

“unauthenticated attacker with access to the pod network” /yawn

deleted 2y ago
[deleted]

liveoneggs 2y ago

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.

tptacek 2y ago
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.
- mort96 2y ago
  Score 9.8 ought to mean, "this is almost the worst conceivable vulnerability".
  - more_corn 2y ago
    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.
    - mort96 2y ago
      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.
      - cjbprime 2y ago
        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.
        mort96 2y ago
        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".

deleted 2y ago

[deleted]

formerly_proven 2y ago

4x “stuff dumped into a configuration file verbatim” 1x “just run the code, CJ”

AcidBurn 2y ago

Resolved in ingress-nginx v1.11.5/v1.12.1 neither of which seem to have been released yet.

AcidBurn 2y ago
Looks like the container images for both versions are now available: registry.k8s.io/ingress-nginx/controller:v1.12.1 registry.k8s.io/ingress-nginx/controller:v1.11.5 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: controller: image: tag: "v1.12.1"
- numbsafari 2y ago
  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. [1] https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...
- AcidBurn 2y ago
  For the sake of completeness I will also mention that the updated Helm chart is now also available: ingress-nginx: 4.12.1

waltercool 2y ago

[dead]

frereit 2y ago

> January 9, 2025 – Kubernetes proposed a fix for CVE-2025-1097. > January 10, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1097. > January 12, 2025 – Kubernetes proposed a fix for CVE-2025-1974. > January 16, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1974. > January 20, 2025 – Kubernetes proposed a fix for CVE-2025-24513. > January 21, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-24513. Lol, lmao even. [1] [1]: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...

philipwhiuk 2y ago
The CVE numbering is interesting.

rcconf 2y ago

I am a little confused about the comment section about this being overblown, it really isn't. Ignore all the comments in this post and fix this ASAP. Here's a simple test: `kubectl exec -it` a pod: curl -k --fail https://ingress-nginx-controller-admission.ingress-nginx.svc.cluster.local https://ingress-nginx-controller-admission.ingress-nginx.svc... 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.