IngressNightmare : CVE-2025-1974 Vulnérabilité et remédiation d'exécution de code à distance

Le mois de mai 2025 a marqué la divulgation publique d'une vulnérabilité de sécurité critique, CVE-2025-1974, surnommée IngressNightmare, affectant le contrôleur Kubernetes ingress-nginx largement déployé dans les infrastructures natives du cloud. Cette vulnérabilité permet à des attaquants non authentifiés d'injecter des configurations arbitraires dans NGINX, ce qui peut potentiellement conduire à une exécution de code à distance (RCE) non autorisée et à la compromission complète du cluster.

Dans le cadre du programme de bourses OPSWAT , nos boursiers ont effectué une analyse technique approfondie afin de mieux comprendre la cause première, la voie d'exploitation et les stratégies d'atténuation de ce problème d'une grande gravité.

1. Chaque configuration est analysée et transmise à generateTemplate pour être formatée selon les modèles NGINX prédéfinis.
2. Ensuite, testTemplate valide la configuration générée par rapport au binaire NGINX sous-jacent.

Toutes les configurations NGINX sont basées sur des modèles prédéfinis qui se trouvent dans le fichier nginx.tmpl du code source d'ingress-nginx :

Dans la fonction generateTemplate, la configuration est traitée comme indiqué dans l'extrait de code suivant :

Cependant, la validation et l'assainissement des entrées sont insuffisants. Plus précisément, le champ uid d'un objet Ingress est directement inséré dans le modèle de configuration NGINX, créant ainsi un point d'injection. Un attaquant peut exploiter ce point en fournissant une entrée élaborée telle que uid="1234#;\n\n}\n}\n}\n injection_value".

Cette entrée malveillante permet l'injection de portée globale dans le modèle NGINX, ce qui permet aux attaquants de déclencher des directives NGINX arbitraires et d'obtenir potentiellement un RCE.

Pour exploiter la vulnérabilité, un attaquant doit identifier une directive capable d'exécuter un code malveillant. Initialement, nos collègues ont identifié la directive load_module comme potentiellement utile, car cette directive permet à NGINX de charger des plugins externes. Cependant, cette directive n'est autorisée que dans la première phase de l'analyse de la configuration, ce qui ne correspond pas à notre point d'injection.

Pour résoudre ce problème, nous avons poursuivi nos recherches, qui ont abouti à la directive ssl_engine, décrite comme "Le module peut être chargé dynamiquement par OpenSSL pendant les tests de configuration". Cette directive a suscité la curiosité en raison de sa capacité à charger dynamiquement des modules, ce qui a nécessité un examen plus approfondi.

Au démarrage, NGINX charge son état initial, puis analyse les fichiers de configuration ligne par ligne. Chaque directive est gérée par la structure nginx_command_t, la directive ssl_engine invoquant directement les ngx_openssl_commands.

En analysant la fonction ngx_openssl_commands, nos collègues ont découvert qu'elle s'appuie sur le support OpenSSL, en particulier la fonction ENGINE_by_id qui est utilisée pour les modules SSL à accélération matérielle.

En analysant la fonction ENGINE_by_id, nous avons constaté qu'elle permet le chargement dynamique des bibliothèques partagées. De plus, si la bibliothèque est compilée avec l'extension __attribute__((constructor)), la fonction associée peut être exécutée immédiatement après le chargement. Ceci indique qu'en exploitant la directive ssl_engine, un attaquant pourrait charger des bibliothèques partagées arbitraires sur l'hôte, conduisant potentiellement à un RCE.

Par défaut, lorsqu'une requête entrante dépasse 8 Ko, NGINX écrit le corps de la requête dans un fichier temporaire situé dans /tmp/nginx/client-body, en utilisant un nom de fichier au format cfg-{valeur_aléatoire}. Ces fichiers temporaires sont conservés jusqu'à 60 secondes entre les morceaux réussis d'un message reçu.

Après avoir écrit un corps de requête partiel dans un fichier temporaire, NGINX reporte la suppression jusqu'à ce que le corps entier soit reçu. Si la requête reste incomplète et qu'aucune donnée n'est reçue pendant 60 secondes, le fichier est finalement purgé. Cependant, en retenant intentionnellement le dernier morceau de données, un attaquant peut maintenir le fichier temporaire en usage, le rendant ainsi exploitable.

Bien que le contenu du fichier téléchargé puisse être contrôlé, il est difficile de le localiser sur le système de fichiers en raison du nom de fichier aléatoire. Le chemin de stockage peut être configuré à l'aide de client_body_temp_path, mais le nom de fichier est généré aléatoirement au moment de l'exécution, ce qui le rend imprévisible. Ce caractère aléatoire entrave considérablement l'accès ciblé, même par force brute. Pour y remédier, l'équipe a exploité des comportements inhérents au système d'exploitation Linux. Prenons l'exemple suivant :

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

Après compilation, la taille de la bibliothèque partagée résultante dépassait largement les 8 Ko, ce qui lui permettait d'être mise en mémoire tampon par NGINX sans nécessiter de rembourrage supplémentaire.

Nos collègues ont ensuite élaboré une requête avec une valeur de longueur de contenu gonflée (par exemple, 1 Mo) afin d'introduire un décalage de taille. NGINX a alors mis en mémoire tampon l'ensemble du corps de la requête au lieu de le traiter immédiatement, ce qui a permis d'écrire l'objet partagé à un emplacement prévisible.

Pour que le RCE réussisse, il faut que la directive ssl_engine fasse référence au chemin d'accès correct au fichier mis en mémoire tampon. Cela peut être réalisé par un script automatisé de force brute qui itère systématiquement sur les combinaisons possibles d'ID de processus et de descripteurs de fichiers pour identifier le lien symbolique valide pointant vers l'objet partagé mis en mémoire tampon.

Vous trouverez ci-dessous un exemple du modèle NGINX généré qui a déclenché l'exploit.

En cas d'exploitation réussie, l'attaquant peut obtenir un accès shell dans le contexte du pod ingress-nginx, qui par défaut a accès aux secrets sensibles du cluster Kubernetes.