Az NGINX 1.31.0-ban egy új, javítatlan zero-day sérülékenységet azonosítottak, amelyet „nginx-poolslip” néven emlegetnek. A leírás szerint a hiba lehetővé teheti az ASLR megkerülését, majd végső soron távoli kódfuttatást is eredményezhet. Mivel az NGINX a világ aktív webhelyeinek nagyjából egyharmadát szolgálja ki, az érintett rendszerek száma potenciálisan rendkívül magas lehet. A hiba különösen aggasztó, mert a legfrissebb mainline kiadást, az 1.31.0-t is érinti.

Az NGINX egy webszerver szoftver, amely az internet körülbelül egyharmadát hajtja. Szinte minden webhely, online áruház vagy alkalmazás mögött ott van valamilyen formában. Ha valaki meglátogat egy weboldalt, szinte biztosan csatlakozott egy NGINX szerverre. Ez a szoftver kezeli a beérkező webes kéréseket, irányítja azokat a megfelelő helyre, és visszaküldi a választ a böngészőnek.

A felfedezés különlegessége, hogy a problémát Vega, a Nebula Security autonóm biztonsági rendszere azonosította, miközben az emberi elemzők az előző NGINX-rift javításának környezetét vizsgálták. Ez jól mutatja, hogy a mai sérülékenységkutatásban már nem csak a manuális vizsgálatok, hanem az automatizált rendszerek is fontos szerepet játszanak. A publikált bemutató szerint a támadás több, egymásra épülő lépésből áll: távoli memóriaminta felmérésből, heap manipulációból, címkiszivárogtatásból és végül kódfuttatásból.

A gond az NGINX belső memóriakezeléséhez kapcsolódik. Az ilyen hibák azért veszélyesek, mert a program nem megfelelően kezeli az általa lefoglalt memóriát, és ez memória-korrupcióhoz vezethet. Ez önmagában még lehetne „csak” összeomlás, de komolyabb esetekben a támadó ezt tovább tudja fordítani kódfuttatásra is.

A bemutatott támadási lánc nem áll meg a hibánál. A támadó távolról, http kérésekkel képes a memóriakezelési viselkedést befolyásolni, majd a memóriában olyan állapotot előidézni, amelyben a védekezési mechanizmusok, köztük az ASLR, megkerülhetővé válhatnak. Az ASLR célja az lenne, hogy a programok memóriacímei ne legyenek kiszámíthatók, így egy támadó ne tudjon pontosan célba venni kritikus struktúrákat. Ha ezt sikerül megkerülni, a hiba sokkal könnyebben válhat teljes kompromittálássá.

A védekezés első lépése a hivatalos javítás mielőbbi telepítése, amint az elérhetővé válik. Addig érdemes csökkenteni az NGINX közvetlen internetes kitettségét, szigorítani a WAF-szabályokat, és figyelni a gyanúsan sok, ismétlődő HTTP kérést. Fontos továbbá az NGINX worker folyamatok monitorozása, különösen akkor, ha azok váratlan shellt vagy szokatlan folyamatot indítanak.