[Ingress-nginx Security Advisory] CVE-2023-5044: Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation

1,955 views
Skip to first unread message

CJ Cullen

unread,
Oct 25, 2023, 12:29:32 PM10/25/23
to kubernete...@googlegroups.com, d...@kubernetes.io, kubernetes-sec...@googlegroups.com, kubernetes-se...@googlegroups.com, distributo...@kubernetes.io, kubernetes+a...@discoursemail.com

Issue Details

A security issue was identified in ingress-nginx where the nginx.ingress.kubernetes.io/permanent-redirect annotation on an Ingress object (in the `networking.k8s.io` or `extensions` API group) can be used to inject arbitrary commands, and 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-2023-5044.

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`.


If you are running the “chrooted” ingress-nginx controller introduced in v1.2.0 (gcr.io/k8s-staging-ingress-nginx/controller-chroot), command execution is possible but credential extraction is not, so the High severity does not apply.


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

Affected Versions

  • <v1.9.0

Versions allowing mitigation

  • v1.9.0

Mitigation

Ingress Administrators should set the --enable-annotation-validation flag to enforce restrictions on the contents of ingress-nginx annotation fields.

Detection

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

Additional Details

See ingress-nginx Issue #10572 for more details.

Acknowledgements

This vulnerability was reported by Jan-Otto Kröpke (Cloudeteer GmbH)


Thank You,

CJ Cullen on behalf of the Kubernetes Security Response Committee


Reply all
Reply to author
Forward
0 new messages