V rozv\u00edjej\u00edc\u00ed se aplikaci Kubernetes ingress-kontroleru ingress-nginx byly odhaleny \u010dty\u0159i zranitelnosti, kter\u00e9 umo\u017e\u0148uj\u00ed prov\u00e9st spu\u0161t\u011bn\u00ed vlastn\u00edho k\u00f3du na serverech cloudov\u00fdch syst\u00e9m\u016f vyu\u017e\u00edvaj\u00edc\u00edch platformu Kubernetes a z\u00edskat pln\u00fd privilegovan\u00fd p\u0159\u00edstup k clusteru Kubernetes. Probl\u00e9m\u016fm byla p\u0159i\u0159azena kritick\u00e1 \u00farove\u0148 nebezpe\u010dnosti (9.8 z 10). V\u00fdzkumn\u00edci, kte\u0159\u00ed odhalili probl\u00e9my, p\u0159i\u0159adili zranitelnostem k\u00f3dov\u00e9 jm\u00e9no IngressNightmare a poznamenali, \u017ee se zranitelnosti dot\u00fdkaj\u00ed p\u0159ibli\u017en\u011b 43 % cloudov\u00fdch prost\u0159ed\u00ed. Zranitelnosti byly odstran\u011bny ve verz\u00edch ingress-nginx 1.11.5 a 1.12.1. <\/p>\n
Ingress kontrol\u00e9r funguje jako br\u00e1na a pou\u017e\u00edv\u00e1 se v Kubernetes k organizaci p\u0159\u00edstupu ze vn\u011bj\u0161\u00ed s\u00edt\u011b k slu\u017eb\u00e1m uvnit\u0159 clustru. Kontrol\u00e9r ingress-nginx je nejpopul\u00e1rn\u011bj\u0161\u00ed a vyu\u017e\u00edv\u00e1 server<\/a> NGINX pro p\u0159esm\u011brov\u00e1n\u00ed po\u017eadavk\u016f na cluster, sm\u011brov\u00e1n\u00ed extern\u00edch po\u017eadavk\u016f a vyva\u017eov\u00e1n\u00ed z\u00e1t\u011b\u017ee. Projekt Kubernetes poskytuje z\u00e1kladn\u00ed ingress-kontrolery pro AWS, GCE a nginx, co\u017e nen\u00ed nijak spojeno s kontrolerem kubernetes-ingress, jeho\u017e \u00fadr\u017ebu zaji\u0161\u0165uje spole\u010dnost F5\/NGINX (zmi\u0148ovan\u00e9 zranitelnosti se net\u00fdkaj\u00ed projekt\u016f vyv\u00edjen\u00fdch v\u00fdvoj\u00e1\u0159i NGINX, zm\u00ednka o nginx v n\u00e1zvu ingress-nginx souvis\u00ed pouze s vyu\u017eit\u00edm nginx jako proxy). <\/p>\n Zranitelnosti umo\u017e\u0148uj\u00ed neautentizovan\u00e9mu \u00fato\u010dn\u00edkovi prov\u00e9st spu\u0161t\u011bn\u00ed vlastn\u00edho k\u00f3du v kontextu kontroleru ingress-nginx s mo\u017enost\u00ed odesl\u00e1n\u00ed po\u017eadavku na webov\u00fd zpracovatel Admission. B\u011bhem skenov\u00e1n\u00ed s\u00edt\u011b bylo odhaleno v\u00edce ne\u017e 6500 zraniteln\u00fdch cluster\u016f Kubernetes, kter\u00e9 vyu\u017e\u00edvaj\u00ed ve\u0159ejn\u011b dostupn\u00e9 zraniteln\u00e9 kontrolery s otev\u0159en\u00fdm zpracovatelem Admission pro extern\u00ed po\u017eadavky. <\/p>\n Ve v\u00fdchoz\u00ed konfiguraci m\u016f\u017ee spu\u0161t\u011bn\u00fd k\u00f3d \u00fato\u010dn\u00edka z\u00edskat p\u0159\u00edstup k nastaven\u00edm objektu Ingress, kde jsou mimo jin\u00e9 ulo\u017eeny i p\u0159ihla\u0161ovac\u00ed \u00fadaje pro p\u0159\u00edstup k server\u016fm Kubernetes, co\u017e umo\u017e\u0148uje z\u00edsk\u00e1n\u00ed privilegovan\u00e9ho p\u0159\u00edstupu k cel\u00e9mu cloudu. Jako obranou strategii se doporu\u010duje deaktivovat v ingress-nginx funkci \u201eValidating Admission Controller\u201c. <\/p>\n Kontroler Admission b\u011b\u017e\u00ed v samostatn\u00e9m pod-okol\u00ed a prov\u00e1d\u00ed operaci ov\u011b\u0159ov\u00e1n\u00ed p\u0159\u00edchoz\u00edch ingress-objekt\u016f p\u0159ed jejich nasazen\u00edm. Ve v\u00fdchoz\u00edm nastaven\u00ed webov\u00fd zpracovatel Admission p\u0159ij\u00edm\u00e1 po\u017eadavky bez autentizace z ve\u0159ejn\u00e9 s\u00edt\u011b. B\u011bhem ov\u011b\u0159ov\u00e1n\u00ed kontroler Admission vytv\u00e1\u0159\u00ed konfiguraci pro http-server nginx na z\u00e1klad\u011b obsahu p\u0159ijat\u00e9ho ingress-objektu a kontroluje jej\u00ed spr\u00e1vnost. <\/p>\n Odhalen\u00e9 zranitelnosti umo\u017e\u0148uj\u00ed z\u00edsk\u00e1n\u00ed vlastn\u00edch nastaven\u00ed v nginx prost\u0159ednictv\u00edm odesl\u00e1n\u00ed speci\u00e1ln\u011b tvarovan\u00e9ho ingress-objektu p\u0159\u00edmo do Admission Controller. V\u00fdzkumn\u00edci zjistili, \u017ee n\u011bkter\u00e9 vlastnosti ov\u011b\u0159ovac\u00edch po\u017eadavk\u016f uveden\u00e9 v poli \u201e.request.object.annotations\u201c jsou p\u0159\u00edmo vkl\u00e1d\u00e1ny do konfigurace nginx. P\u0159itom generovan\u00e1 konfigurace nen\u00ed aplikov\u00e1na, ale pouze testov\u00e1na spu\u0161t\u011bn\u00edm spustiteln\u00e9ho souboru \u201enginx\u201c s volbou \u201e-t.\u201c <\/p>\n Konkr\u00e9tn\u011b je vkl\u00e1d\u00e1n\u00ed extern\u00edch dat do konfigurace prov\u00e1d\u011bno pro parametry \u201emirror-target\u201c, \u201emirror-host\u201c (CVE-2025-1098), \u201eauth-tls-match-cn\u201c (CVE-2025-1097) a \u201eauth-url\u201c (CVE-2025-24514). Nap\u0159\u00edklad v \u0159\u00e1dku konfigurace \u201eset $target {{ $externalAuth.URL }};\u201c je m\u00edsto \u201e{{ $externalAuth.URL }}\u201c vkl\u00e1d\u00e1n URL uveden\u00fd v parametru \u201eauth-url\u201c. P\u0159itom nen\u00ed kontrolov\u00e1na spr\u00e1vnost URL. \u00dato\u010dn\u00edk tak m\u016f\u017ee p\u0159edat jako URL hodnotu typu \u201ehttp:\/\/example.com\/#;\n nastaven\u00ed\u201c a vlo\u017eit sv\u00e9 vlastn\u00ed nastaven\u00ed do konfigura\u010dn\u00edho souboru. <\/p>\n Pro vykon\u00e1n\u00ed libovoln\u00e9ho k\u00f3du b\u011bhem kontroly konfigurace p\u0159\u00edkazem \u201enginx -t\u201c v\u00fdzkumn\u00edci vyu\u017eili toho, \u017ee krom\u011b kontroly syntaxe nginx na\u010d\u00edt\u00e1 knihovny s moduly a otev\u00edr\u00e1 soubory uveden\u00e9 v konfiguraci pro posouzen\u00ed jejich dostupnosti. Mezi jin\u00fdm, p\u0159i zpracov\u00e1n\u00ed direktivy ssl_engine se na\u010d\u00edt\u00e1 sd\u00edlen\u00e1 knihovna uveden\u00e1 v direktiv\u011b. SSL<\/a>-enginu. <\/p>\n K tomu, aby se jejich knihovna nahr\u00e1la na server Kubernetes, v\u00fdzkumn\u00edci vyu\u017eili (CVE-2025-1974) skute\u010dnosti, \u017ee p\u0159i zpracov\u00e1n\u00ed velk\u00fdch po\u017eadavk\u016f nginx uchov\u00e1v\u00e1 t\u011blo po\u017eadavku do do\u010dasn\u00e9ho souboru, kter\u00fd je okam\u017eit\u011b smaz\u00e1n, ale v souborov\u00e9m syst\u00e9mu «\/proc» z\u016fst\u00e1v\u00e1 pro tento soubor otev\u0159en\u00fd deskriptor. T\u00edmto zp\u016fsobem lze sou\u010dasn\u011b zas\u00edlat po\u017eadavky na uchov\u00e1n\u00ed do\u010dasn\u00e9ho souboru a zaji\u0161t\u011bn\u00ed kontroly konfigurace, v n\u00ed\u017e je v direktiv\u011b «ssl_engine» uvedena cesta k deskriptoru v souborov\u00e9m syst\u00e9mu «\/proc». <\/p>\n Aby deskriptor souboru z\u016fstal po dlouhou dobu dostupn\u00fd, lze uv\u00e9st hodnotu «Content-Length» v po\u017eadavku jako zjevn\u011b v\u011bt\u0161\u00ed, ne\u017e jsou skute\u010dn\u011b p\u0159ed\u00e1van\u00e1 data (server bude \u010dekat na p\u0159evzet\u00ed zb\u00fdvaj\u00edc\u00edch dat). Dal\u0161\u00ed komplikac\u00ed je pot\u0159eba uhodnout PID procesu a \u010d\u00edslo deskriptora souboru spojen\u00e9ho s nahranou sd\u00edlenou knihovnou, ale proto\u017ee v kontejneru se obvykle pou\u017e\u00edv\u00e1 minim\u00e1ln\u00ed po\u010det spu\u0161t\u011bn\u00fdch proces\u016f, pot\u0159ebn\u00e9 hodnoty se uhodnou pomoc\u00ed n\u011bkolika pokus\u016f. V p\u0159\u00edpad\u011b \u00fasp\u011bchu a nahr\u00e1n\u00ed zadan\u00e9 sd\u00edlen\u00e9 knihovny m\u016f\u017ee \u00fato\u010dn\u00edk z\u00edskat p\u0159\u00edstup k parametr\u016fm ulo\u017een\u00fdm uvnit\u0159 pod-\u010dlensk\u00e9ho prost\u0159ed\u00ed, kter\u00e9 jsou dostate\u010dn\u00e9 pro spr\u00e1vu cel\u00e9ho clusteru.