» »

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

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.

2 komentarja

denial ::

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.

Bug je bil reportan 11.1.2012, patchan pa slab mesec kasneje in to šele potem, ko ga je ponovno reportal respected security researcher kar je dvignilo veliko medijskega pompa.
SELECT finger FROM hand WHERE id=3;

Zgodovina sprememb…

  • spremenil: denial ()

Spura ::

Joj dej ze nehi blejat o tej odprtosti. Nobody gives a shit. In pa kaj ima code coverage veze tukaj? A hoces rect, da popravek ni bil stestiran?


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Facebookov luknjast antispam filter

Oddelek: Novice / Varnost
62650 (1436) Markoff
»

Kritična ranljivost vprotokolu DNS

Oddelek: Informacijska varnost
51685 (1536) fiction
»

0-day exploits = 0-year exploits

Oddelek: Novice / Varnost
153772 (2676) MrStein
»

Vzpostavljanje prikritih omrežij s pomočjo XSS ranljivosti in JavaScripta

Oddelek: Novice / Varnost
224860 (3569) MrStein
»

Dobrodošli v preteklost...

Oddelek: Novice / Ostala programska oprema
184189 (2938) MrStein

Več podobnih tem