Should the invalidSecretsDir regex be updated to /run/secrets? In the default ingress-nginx image, /var/run is symlinked to /run, so the service account token can be accessed through /run/secrets:

bash-5.1$ ls -l /var/run
lrwxrwxrwx    1 root     root             4 Apr  4 16:07 /var/run -> /run
bash-5.1$ ls -l /run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx    1 root     root            13 Apr 22 17:44 ca.crt -> ..data/ca.crt
lrwxrwxrwx    1 root     root            16 Apr 22 17:44 namespace -> ..data/namespace
lrwxrwxrwx    1 root     root            12 Apr 22 17:44 token -> ..data/token
bash-5.1$ 

Updating the regex to /run/secrets would block both paths.

/triage accepted
/priority critical-urgent

@cjcullen , I am trying to experience this exploit in a instance of the ingress-nginx-controller, with chroot enabled on the nginx process.

Can you help me gt a example value for the spec ingress.spec.rules[].http.paths[].path that will demonstrate this vulnerability, on a chrooted nginx process of the controller.

We were recently notified about this CVE. I see this seems to be fixed in v1.2.0.
Is there anything except from updating to the latest version required to mitgate this type of exploit?

@foxylion yes, we are providing a Kyverno policy in the above linked PR (kyverno/policies#302)

@chipzoller This is only an alternative, if I can't update, correct?
From the CVE it sounds as if the whole fix is included in ingress-nginx v1.2.0.

As the rules for deep inspect are hard-coded in the code.
Also as mentioned above by @fhke some rules are missed.
So it doesn't look like fixed in 1.2.0 just by upgrading.
May be just like bad annotation list these rules also should be exposed to user.

@strongjz @rikatz any comments on this being completely fixed in 1.2.0

@bmv126 this was discussed in the last community meeting. Maintainers were aware of this and are working on it from even before the issue was created or maybe even before the CVE was published.

The controller v1.20 introduces capability to jail/charoot the nginx process so it has been tested that the obvious use case of getting a shell, by breaking out of the nginx process, will land the actor in a jailed/chrooted shell, if at all. That is one layer of protection.

If you want to discuss further, it was reported that users can use this link https://github.com/kubernetes/ingress-nginx/blob/main/SECURITY.md and be discreet about putting sensitive info in public places. You could also reach out to maintainers without including groups in such communication, so as to reduce the radius for info spread.

@bmv126 can you please open a PR adding the new rules?

As the main code to fix this is shipped, I'm going to close this issue but I have some additional rules myself I want to add as well :)

/close

@rikatz: Closing this issue.

/transfer kubernetes
/area security
/kind bug
/committee security-response
/triage accepted
/lifecycle frozen
/label official-cve-feed

@cji: The label(s) /label official-cve-feed cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

/area security
/kind bug
/committee security-response
/triage accepted
/lifecycle frozen
/label official-cve-feed