CVE-2021-25746: Ingress-nginx directive injection via annotations

[cjcullen]

Issue Details

A security issue was discovered in ingress-nginx where a user that can create or update ingress objects can use .metadata.annotations in an Ingress object (in the networking.k8s.io or extensions API group) to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to 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-25746.

Affected Components and Configurations

This bug affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected. You can check this by running kubectl get po -n ingress-nginx.

Multitenant environments where non-admin users have permissions to create Ingress objects are most affected by this issue.

Affected Versions

• <v1.2.0

Fixed Versions

• v1.2.0-beta.0
• v1.2.0

Mitigation

If you are unable to roll out the fix, this vulnerability can be mitigated by implementing an admission policy that restricts the metadata.annotations values to known safe (see the newly added rules, or the suggested value for annotation-value-word-blocklist).

Detection

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Additional Details

See ingress-nginx Issue #8503 for more details.

Acknowledgements

This vulnerability was reported by Anthony Weems, and separately by jeffrey&oliver.

Thank You,
CJ Cullen on behalf of the Kubernetes Security Response Committee

[strongjz]

/triage accepted
/priority critical-urgent

[bmv126]

The issue talks about injection via annotation.
The deepInpect added in 1.2.0 does not check for annotation.
Not sure how is this fixed in 1.2.0

[longwuyuan]

@bmv126 the report itself says the CVE applies to release pre v1.2.0 so checking if there is a prescribed demonstrated way to see the exploit in action.

On v1.2.0 I installed the helm chart with --set controller.image.chroot=true, and now I am trying to create a ingress with a annotation that will demo this vulnerability. Do you have any thoughts on what annotation I can configure in a ingress to experience this exploit. I think the idea is to get access to a serviceaccount by breaking out of the nginx process with a clever annotation but I can't think of a good annotation (both key and value) to try. I think a publicly visible demo with the nginx process jailed/chrooted, will help make progress.

[foxylion]

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?

[yinfuqian]

Is there any way to reproduce this problem

[longwuyuan]

Please try to avoid public display of exploit and you can try to enable chroot image while installing the controller v1.2.0 to enable the jailing/chrooting of the nginx process.

[yinfuqian]

I hope I can see the actual impact of this problem, so I hope to reproduce this problem in the test environment. How can I deal with it

[longwuyuan]

https://kubernetes.io/blog/2022/04/28/ingress-nginx-1-2-0/

[rikatz]

This was fixed in v1.2.0

We plan to add more rules to the inspection

/close

[k8s-ci-robot]

@rikatz: Closing this issue.

In response to this:

This was fixed in v1.2.0

We plan to add more rules to the inspection

/close

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.

[cji]

/transfer kubernetes

[cji]

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