A Kubernetes ingress controller project called ingress-nginx has revealed four vulnerabilities that allow the execution of arbitrary code on cloud system servers using the Kubernetes platform, resulting in full privileged access to the Kubernetes cluster. The vulnerabilities have been assigned a critical severity level (9.8 out of 10). Researchers identifying these issues have code-named the vulnerabilities IngressNightmare, noting that they affect approximately 43% of cloud environments. The vulnerabilities have been fixed in ingress-nginx versions 1.11.5 and 1.12.1.
The ingress controller acts as a gateway and is used in Kubernetes to facilitate access from an external network to services within the cluster. The ingress-nginx controller is the most popular and utilizes szerver NGINX is used for proxying requests to the cluster, routing external requests, and load balancing. The Kubernetes project provides basic ingress controllers for AWS, GCE, and nginx, the latter of which is not related to the kubernetes-ingress controller maintained by F5/NGINX (the vulnerabilities discussed do not affect projects developed by NGINX developers; the mention of nginx in the name ingress-nginx is solely related to using nginx as a proxy).
The vulnerabilities allow an unauthenticated attacker to execute arbitrary code in the context of the ingress-nginx controller when it is possible to send a request to the Admission web handler. During network scanning, over 6,500 vulnerable Kubernetes clusters were identified using publicly accessible vulnerable controllers with an Admission handler open to external requests.
In the default configuration, the attacker's code can access the Ingress object's settings, which include credentials for accessing Kubernetes servers, allowing for privileged access to the entire cluster. To protect against this, it is recommended to disable the 'Validating Admission Controller' feature in ingress-nginx.
The Admission controller runs in a separate pod environment and performs the verification of incoming ingress objects before their deployment. By default, the Admission web handler accepts unauthenticated requests from the public network. During the verification process, the Admission controller creates a configuration for the nginx http server based on the contents of the received ingress object and checks its correctness.
A felfedezett sebezhetőségek lehetővé teszik, hogy saját beállításokat illesszenek be az nginx-be egy speciálisan formázott ingress-objektum közvetlen elküldésével az Admission vezérlőnek. A kutatók felfedezték, hogy bizonyos ellenőrző kérdések tulajdonságai, amelyeket a „.request.object.annotations” mezőbe állítanak be, közvetlenül beépülnek az nginx konfigurációjába. Ezáltal a generált konfigurációt nem alkalmazzák, csupán tesztelik az „nginx” végrehajtható fájl „-t” opcióval történő futtatásával.
Különösen, a külső adatok beillesztése a konfigurációba a „mirror-target”, „mirror-host” (CVE-2025-1098), „auth-tls-match-cn” (CVE-2025-1097) és „auth-url” (CVE-2025-24514) paraméterek esetében történik. Például a „set $target {{ $externalAuth.URL }};” konfigurációs sorban a „{{ $externalAuth.URL }}” helyett a „auth-url” paraméterben megadott URL kerül beillesztésre. A megadott URL helyességét nem ellenőrzik. Ennek megfelelően a támadó átadhat egy URL-t, például „http://example.com/#; beállítások” formátumban, és saját beállításait beillesztheti a konfigurációs fájlba.
Tetszőleges kód végrehajtásához a konfiguráció ellenőrzése során az „nginx -t” parancs használatával a kutatók kihasználták, hogy az nginx a szintaxis ellenőrzése mellett betölti a modulokkal rendelkező könyvtárakat és megnyitja a konfigurációban említett fájlokat azok elérhetőségének értékelésére. Különösen, az ssl_engine utasítás feldolgozása során a megadott megosztott könyvtár betöltésére kerül sor. SSL-motor.
A Kubernetes szerverre való saját könyvtárának betöltéséhez a kutatók (CVE-2025-1974) kihasználták, hogy az nginx nagyobb kérések feldolgozása során a kérés testét átmeneti fájlban tárolja, amelyet azonnal törölnek, de a fájlrendszerben a „/proc” ezen fájlhoz nyitott fájlleírója megmarad. Így egyidejűleg kéréseket lehet küldeni az átmeneti fájl megőrzésére és a konfiguráció ellenőrzésének kezdeményezésére, amelyben az „ssl_engine” utasításban a fájlrendszer „/proc” fájlleírójához vezető útvonal van megadva.
A fájlt leíró foglalat hosszan tartó elérhetőségéhez a "Content-Length" a kérésben kifejezetten nagyobb értékkel adható meg, mint amennyi ténylegesen átadott adat áll rendelkezésre (a szerver meg fogja várni a fennmaradó adatok beérkezését). További bonyodalmat okoz a PID folyamat és a feltöltött megosztott könyvtárhoz kapcsolódó fájlt leíró számának kitalálása, de mivel a konténerben általában minimális számú futó folyamat használatos, a szükséges értékeket több próbálkozás segítségével lehet kitalálni. Siker esetén, és ha a helyettesítő megosztott könyvtár betöltésre kerül, a támadó hozzáférést nyerhet a pod-környezetben tárolt paraméterekhez, amelyek elegendőek az egész klaszter irányításához.
A sebezhető ingress-nginx használatának ellenőrzésére a következő parancsot lehet végrehajtani: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Forrás: opennet.ru
