Prejšnji popravek za PHP povzročil še več škode

PHP - Minuli četrtek je izšel nujni varnostni popravek 5.3.10 za priljubljeni skriptni jezik PHP. Kot se je izkaže, so razvijalci med reševanjem precej manjšega varnostnega problema v predprejšnji različici (10.1. letos) nehote odprli vrata za mnogo resnejšo napako, ki omogoča celo oddaljeno izvršitev napadalčeve kode.

Izvorna napaka v PHP <= 5.3.8 je zadevala funkcijo za sprejem parametrov HTTP zahtevka (v stilu iskalnik.php?q=slo-tech&orderby=date). Posamezni parametri so se najprej primerjali po njihovi zgoščeni vrednosti (hash) in kot vemo, ima lahko več različnih nizov isti hash, vendar je sorazmerno težko najti še en niz z že določenim hashem. Napad, za katerega obstaja tudi proof-of-concept exploit (PoC), je zoper php strežnik poslal gručo zahtevkov z več tisoč parametri, od katerih so mnogi imeli isto zgoščeno vrednost. To je na določenih strežnikih lahko povzročilo preobremenitev sistema in s tem DOS (denial of service) napad.

Popravek 5.3.9 je preprosto dodal novo php.ini nastavitev max_input_vars, ki omeji možno število parametrov v enem zahtevku in s tem število hashev, ki jih je potrebno izračunati na vsak zahtevek. Po privzetem je ta vrednost 1000 - več kot preveč za skoraj vse aplikacije - zato je popravek hitro šel skozi. Žal pa so pri testiranju pozabili na robno situacijo, ki nastopi, če napadalec pošlje mejno število paremetrov in še enega, katerega vrednost je polje (array - videno npr. pri checkboxih in listboxih). V tem primeru je mogoče s spretno oblikovanim zadnjim parametrom sesuti php proces oz. celo doseči izvršitev poljubne kode. PoC je seveda spet na voljo, podrobnosti so pa tukaj.

Po besedah prijavitelja je nekoliko ironično, da nova napaka deluje na bistveno več strežnikih kot bi bilo sicer mogoče, to pa zato, ker je bila uvedena prav za varnostnim popravkom. Ti zaradi svoje resnosti vidijo bistveno večje število namestitev od ostalih popravkov, za njihovo promptno namestitev pa velikokrat poskrbijo že distribucije.

Neprilika lepo izpostavlja potrebo po izdatnem testiranju kode (code coverage), posebej pri ključnih knjižnicah tipa PHP. Seveda pa se je treba tudi zavedati, da je bila odkrita in popravljena sorazmerno hitro, kar je mogoče predvsem zato, ker je jezik v celoti odprt, njegova izvorna koda prosto dosegljiva in široko uporabljana. Zaprte in osamljene rešitve igrajo na karto varnosti skozi obskurnost, ki se dolgoročno izjemno redko splača. Pač velja, da je vsaka nova rešitev nujno še nepreizkušena, ne glede na obljube in sloves njenih proizvajalcev.