Arendatavas Kubernetes ingress-kontrolleri projektis ingress-nginx tuvastati neli haavatavust, mis v\u00f5imaldavad saavutada oma koodi t\u00e4itmist pilves\u00fcsteemide serverites, mis kasutavad Kubernetes platvormi, ning saada t\u00e4ielik privileegide juurdep\u00e4\u00e4s Kubernetes klastrile. Probleemidele on antud kriitilise taseme oht (9.8 10-st). Probleemide avastanud uurijad nimetasid haavatavustega seotud koodinimeks IngressNightmare ja m\u00e4rkisid, et haavatavused m\u00f5jutavad umbes 43% pilveskeskkondadest. Haavatavused on k\u00f5rvaldatud versioonides ingress-nginx 1.11.5 ja 1.12.1. <\/p>\n
Ingress-kontroller toimib v\u00e4ravana ja seda kasutatakse Kuberneteses, et korraldada juurdep\u00e4\u00e4su v\u00e4lisest v\u00f5rgust klastris asuvatele teenustele. Ingress-nginx kontroller on k\u00f5ige populaarsem ja rakendab server<\/a> NGINX edastamiseks p\u00e4ringutele klastrisse, v\u00e4listest p\u00e4ringutest marsruutimiseks ja koormuse tasandamiseks. Kubernetes projekt pakub p\u00f5hilisi ingress-kontrollereid AWS, GCE ja nginx, kusjuures viimane ei ole \u00fcldse seotud kubernetes-ingress kontrolleriga, mille hooldust teostab F5\/NGINX (tuletatud haavatavused ei m\u00f5juta projekte, mida arendavad NGINX arendajad; nginx-i mainimine ingress-nginx nimekirjas on seotud ainult nginx-i kasutamisega proksi). <\/p>\n Haavatavused v\u00f5imaldavad autentimata r\u00fcndajal saavutada oma koodi t\u00e4itmist ingress-nginx kontrolleri kontekstis, saades v\u00f5imaluse saata p\u00e4ring Admission web-teenusele. V\u00f5rgu skaneerimise k\u00e4igus tuvastati \u00fcle 6500 haavatava Kubernetes klastrite, mis kasutavad avalikke haavatavaid kontrollereid avatud Admission k\u00e4sitsemiseks. <\/p>\n Vaikimisi seadistuses v\u00f5ib r\u00fcndeprogramm k\u00e4ivitatud kood p\u00e4\u00e4seda ligi Ingress objekti seadistustele, milles hoitakse muu hulgas ka Kubernetes serverite \u00fchenduse andmeid, mis v\u00f5imaldab privileegide saamist kogu klastrile. Kaitse \u00fcmbersuunamiseks soovitatakse keelata ingress-nginx-is funktsioon \u201eValidating Admission Controller\u201d. <\/p>\n Admission kontroller k\u00e4ivitub eraldi pod-\u00f6konoomikas ja kontrollib sissetulevate ingress-objektide valideerimist enne nende juurutamist. Vaikimisi v\u00f5tab Admission web-teenus vastu autentimata p\u00e4ringud avalikest v\u00f5rkudest. Kontrollimise k\u00e4igus loob Admission kontroller nginx http-serveri konfiguratsiooni l\u00e4htudes saadud ingress-objekti sisust ja kontrollib selle korrektset. <\/p>\n Tuvastatud haavatavused v\u00f5imaldavad Nginx-i seadistuste asendamist, saates spetsiaalselt vormistatud ingress-objekti otse Admission kontrollerisse. Uurijad avastasid, et m\u00f5ned kontrollk\u00fcmnendiku omadused, mis on m\u00e4\u00e4ratud valdkonnas \u201e.request.object.annotations\u201d, sisestatakse otse Nginx-i seadistusse. Garanteeritud konfiguratsiooni ei rakendata, vaid testitakse k\u00e4ivitades t\u00e4itmisfaili \u201enginx\u201d koos valikuga \u201e-t\u201d. <\/p>\n Eelk\u00f5ige toimub v\u00e4liste andmete sisestamine seadistusse parameetritele \u201emirror-target\u201d, \u201emirror-host\u201d (CVE-2025-1098), \u201eauth-tls-match-cn\u201d (CVE-2025-1097) ja \u201eauth-url\u201d (CVE-2025-24514). N\u00e4iteks seadistusreal \u201eset $target {{ $externalAuth.URL }};\u201d asendatakse URL-iga, mis on m\u00e4\u00e4ratud parameetris \u201eauth-url\u201d. \u00dcksikasjalikud URL-de \u00f5igsust ei kontrollita. Seega v\u00f5ib r\u00fcndaja edastada URL-i v\u00e4\u00e4rtuse vormis \u201ehttp:\/\/example.com\/#;\nseaded\u201d ja asendada oma seadistused konfiguratsioonifailis. <\/p>\n Et k\u00e4ivitada suvalist koodi konfiguratsiooni kontrollimise k\u00e4igus k\u00e4suga \u201enginx -t\u201d, kasutasid uurijad seda, et lisaks s\u00fcntaksikontrollile laadib Nginx moodulite raamatukogusid ja avab konfiguratsioonis mainitud faile nende k\u00e4ttesaadavuse hindamiseks. Muuhulgas, ssl_engine direktiivi t\u00f6\u00f6tlemisel laaditakse direktiivis m\u00e4\u00e4ratud jagatud raamatukogu. SSL<\/a>-mootori. <\/p>\n Kubernetesi serverisse oma raamatukogu laadimiseks kasutasid teadlased (CVE-2025-1974) seda, et nginx-i t\u00f6\u00f6tlemise k\u00e4igus salvestatakse suured p\u00e4ringud ajutisse failisse, mis seej\u00e4rel kohe kustutatakse, kuid failis\u00fcsteemis «\\\/proc» j\u00e4\u00e4b selle faili jaoks avatud failideskriptor. Seega on v\u00f5imalik samaaegselt saata p\u00e4ringud ajutise faili salvestamiseks ja algatada konfiguratsiooni kontrolli, kus direktiivis «ssl_engine» on n\u00e4idatud failis\u00fcsteemi «\\\/proc» teed failideskriptorile. <\/p>\n Et failideskriptor p\u00fcsiks juurdep\u00e4\u00e4setav kaua, v\u00f5ib p\u00e4ringus «Content-Length» v\u00e4\u00e4rtuse m\u00e4\u00e4rata eelnevalt suuremaks, kui tegelikult edastatud andmed on (server ootab \u00fclej\u00e4\u00e4nud andmete vastuv\u00f5ttu). T\u00e4iendavaks keerukuseks on vajadus \u00e4ra arvata protsessi PID ja failideskriptor, mis on seotud laaditud jagatud raamatukoguga, kuid kuna konteineris kasutatakse tavaliselt minimaalset arvu t\u00f6\u00f6tavaid protsesse, saab vajalikud v\u00e4\u00e4rtused \u00e4ra arvata mitme katse k\u00e4igus. Edu korral ja sisestatud jagatud raamatukogu laadimise korral v\u00f5ib r\u00fcndaja p\u00e4\u00e4seda ligi pod-\u00fcmbrusesse salvestatud parameetritele, mis on piisavad kogu klastri haldamiseks.