FlawOpen

flawopen.com/Teardowns/cve-2024-7646-ingress-nginx-annotation-code-injection

● CVE-2024-7646 · CVSS 8.8 · Haute
Recherche · FlawOpen

CVE-2024-7646 : contournement de validation Ingress-NGINX

Un retour chariot permettait l’injection de commandes et l’accès aux identifiants du contrôleur. Corrigé en 1.11.2/1.10.4 ; projet retiré.

💡 Explication en Langage Simple (ELI5)

Imaginez un gardien qui vérifie qu’un formulaire contient un mot autorisé, sans valider toute la valeur. Un retour chariot peut modifier l’interprétation du texte restant par le système suivant. Ici, une annotation passait une correspondance partielle avant d’être écrite dans la configuration NGINX générée. Le correctif valide toute la valeur et traite les retours chariot sans danger.

Concepts Clés et Termes

Objet Ingress
Ressource de l’API Kubernetes décrivant le routage d’un hôte ou chemin vers un Service. Certains utilisateurs peuvent la créer sans être administrateurs du cluster.
Contournement de validation d’annotation
Une valeur d’annotation a passé un validateur qui a trouvé une sous-chaîne autorisée, sans exiger que la valeur entière corresponde.
Retour chariot (`\r`)
Caractère de contrôle servant de retour à la ligne dans certains formats. Une interprétation différente entre validation et génération de configuration peut modifier le début des lignes.
Compte de service du contrôleur
Identité Kubernetes utilisée par ingress-nginx. L’avis amont indique que ses permissions par défaut peuvent inclure l’accès à tous les Secrets du cluster.

Correspondances de référentiels

  • Référence CWE pour la faiblesse décrite dans ce guide : CWE-20

Analyse de Cause Racine

CVE-2024-7646 est un contournement de validation des annotations ingress-nginx, et non l’utilisation sans restriction d’un snippet Lua personnalisé. Le validateur auth-tls-verify-client utilisait une expression régulière Go sans ancres de début et de fin ; MatchString pouvait donc accepter une valeur plus longue contenant une option autorisée comme sous-chaîne. Un retour chariot dans l’annotation pouvait ensuite être interprété différemment lors du nettoyage de la configuration NGINX générée. Le correctif amont impose une correspondance sur toute la valeur et traite correctement les retours chariot isolés dans cleanConf. L’avis de sécurité Kubernetes indique qu’un acteur autorisé à créer des objets Ingress peut contourner la validation, injecter des commandes et obtenir les identifiants du contrôleur ; dans la configuration par défaut, ceux-ci peuvent lire tous les Secrets du cluster. Il s’agit d’un chemin authentifié par l’API Kubernetes, de gravité élevée (CVSS 8.8), et non d’une requête réseau anonyme. Le projet a été retiré en mars 2026 ; passer à la version historique corrigée ne constitue qu’un confinement immédiat. Les déploiements doivent migrer vers un contrôleur maintenu ou une implémentation Gateway API.

Déroulement de l'Attaque Étape par Étape

Étape 1

Un utilisateur peut créer un objet Ingress

L’attaquant doit disposer du droit de créer un objet Ingress via l’API Kubernetes. Le risque est particulièrement important dans les clusters multi-tenant où ce droit est délégué aux équipes applicatives.

Étape 2

Une annotation passe par correspondance partielle

L’expression régulière vulnérable de auth-tls-verify-client n’avait pas d’ancres. Go MatchString pouvait donc accepter une valeur plus longue contenant une option permise au lieu d’exiger une valeur exacte.

Étape 3

Le retour chariot franchit la frontière de configuration

L’annotation est intégrée à la configuration NGINX générée. Les correctifs traitent à la fois la validation de la valeur entière et les retours chariot isolés pendant le nettoyage de la configuration.

Étape 4

L’identité du contrôleur est exposée

L’avis Kubernetes indique que l’injection de commandes peut fournir les identifiants du contrôleur. Par défaut, ce compte de service peut lire tous les Secrets ; l’impact dépend du RBAC déployé.

Code Source : Vulnérable vs Sécurisé

Ces extraits viennent des correctifs amont de CVE-2024-7646 : la PR #11719 ancre les valeurs auth-tls-verify-client autorisées et la PR #11721 traite les retours chariot isolés dans cleanConf. La branche 1.10 a reçu les changements correspondants dans les PR #11718 et #11722. Le contexte de fonction non pertinent est omis.

IMPLÉMENTATION VULNÉRABLE
// internal/ingress/annotations/authtls/main.go (avant)
authVerifyClientRegex = regexp.MustCompile(`on|off|optional|optional_no_ca`)

// internal/ingress/controller/template/template.go (avant)
switch c {
case ' ', '\t':
    needOutput = lineStarted
case '\n':
    needOutput = !(!lineStarted && emptyLineWritten)
    nextLineStarted = false
}
PATCH SÉCURISÉ ET ROBUSTE
// internal/ingress/annotations/authtls/main.go (corrigé)
authVerifyClientRegex = regexp.MustCompile(`^(on|off|optional|optional_no_ca)$`)

// internal/ingress/controller/template/template.go (corrigé)
switch c {
case '\r':
    rest := in.Bytes()
    if len(rest) > 0 && rest[0] != '\n' {
        c = ' '
        needOutput = lineStarted
    }
case '\n':
    needOutput = !(!lineStarted && emptyLineWritten)
    nextLineStarted = false
}

Liste de Contrôle de Sécurité pour l'Ingénierie

Sources