Slo-Tech - V Linuxovi knjižnici glibc so odkrili resno ranljivost, ki se je je prijelo ime GHOST (zaradi funkcije GetHOST) in napadalcu omogoča prevzem nadzora nad sistemom. Problematične so funkcije gethostbyname*() (ki kličejo __nss_hostname_digits_dots(), ki je občutljiva na prekoračitev predpomnilnika) v glibc (GNU C Library) v verzijah 2.17 in starejših. Že maja 2013 je sicer izšla verzija 2.18, ki ranljivosti ni več vsebovala, a je tedaj niso prepoznali in označili kot ranljivosti, zato vsi niso izvedli nadgradnje. Qualys so bili prvi, ki so ranljivost tudi identificirali. Prizadeta programska oprema med drugim vključuje clockdiff, procmail, pppd in Exim.
V podjetju Sucuri pa so ugotovili, da so potencialno ranljive vse v PHP napisane aplikacije, ki uporabljajo problematično funkcijo (recimo WordPress), kar bistveno razširi možnosti zlorab, saj je ranljivost mogoče zlorabljati lokalno ali oddaljeno. Recimo, WordPress uporablja funkcijo wp_http_validate_url() za preverjanje URL-naslova pošiljatelja pingbacka, za kar uporabi tudi funcijo gethostbyname(). Na ta način lahko napadalec strežnik z WordPressom pretenta v poganjanje poljubne zlonamerne kode.
Z enostavnim ukazom je mogoče preveriti, ali je vaš spletni strežnik ranljiv. Pri Trustwave SpiderLabs so sestavili dokaz koncepta, ki omogoča preveriti, ali je občutljiv določen spletni strežnik. Uporabniki WordPressa lahko izključijo XML-RPC oziroma blokirajo pingback. Vse večje Linuxove distribucije so tudi že izdale popravke, ki so ranljivost zakrpali. Ni znano, da bi ranljivost kdo že aktivno izkoriščal.
Štiri ure za testiranje in rollout patcha, okoli 7 ur za rolling restart vseh mašin v vseh gručah, brez izgubljenih poizvedb.
Ni slabo za "zastonjski polizdelek" - več kot magnitudo hitreje od najhitrejšega odziva konkurence.
No, še AWS RDS čaka, ampak to je bolj problem vnaprej določenih ponudnikovih rednih vzdrževalnih oken.
Vsekakor resna zadeva z ogromno potenciala za zlorabo v zelo različnih oblikah, a tokrat k sreči manj zoprn popravek kot zadnjič, ko se je bash zaradi popravka začel drugače obnašat.
Seveda, ker je tok resen bug, da ga je treba takoj patchat. Pri konkurenci maš ponavad tud patche, ki jih lahko downloadaš in inštaliraš sam. Folk tega pač ne počne, ker je pol sam kriv za probleme :) Tlele ga pomojem ne bo inštaliralo vsaj 90% wordpress userjev...
Naj mi samo še kdo reče, da Arch in Gentoo ne pašeta na server. Samo še eden.
Razlaga samo za Mavrika, ki rad kdaj kaj preveč pobriše: Arch in Gentoo sta rolling release distribuciji. Večina pravi, da zaradi te svoje narave ne sodita na server, kjer se pričakuje velika stabilnost. Ta novica dokazuje, da utegne biti rolling-release narava dejansko velika prednost.
Če bi bi imel strežnik nek ozek namen ter bil ves čas aktivno nadzorovan, funkcije osnovnih aplikacij testirane ob vsaki posodobitvi, vsaka posodobitev pregledana in odobrena, potem bi Arch funkcioniral čisto ok. Na delovnih postajah se je čisto solidno obnesel, meni osebno je recimo zelo všeč (hint: kdor ni poskusil Archa, naj ga enkrat).
Ampak za večje število strežnikov s širšim področjem uporabe me še vedno nič ni bolj prepričalo od RHEL oz. CentOS-a oz. Scientific Linuxa.
Če bi hotel hitrejše menjave verzij programja bi uporabil Fedoro in nadgrajeval vsakih 6-7 mesecev oz. preskočil po eno verzijo in nadgrajeval vsakih 12-13 mesecev. Fedora v povezavi z VPS-ji, ki se samodejno deployajo ter neko continous integration tehnologijo za vsebino, bi po moje delovala čisto ok. Za bolj skrajni korak pa recimo Arch. Ampak oboje ima precej ožjo uporabnost kot omenjeni RHEL.
V primeru te ranljivosti se je hitro spreminjajoči Arch izkazal za varnejšega. Ampak slučajno. To čisto nič ne pomeni.
And get a segmentation fault, it means your server is vulnerable. Be sure to watch for your distribution's fix for the patch (yum update is your friend).
@pegasus: Kakšnih nepotrebnih težav? Jaz lavfam kvazi produkcijski server na Archu, nisem imel v dveh letih niti enega samega problema. Kakšna bolj resna firma bi si lahko privoščila še en dodaten strežnik, na katerem stestirajo vsak update, preden ga naredijo na produkciji.
novica o luknji, ki je bila pokrpana, kjer je popravek v repotih in bi jo vsak sistemc moral v ... kaj jaz vem, dveh dnevih urediti? Kr neki. To je samo dokaz, da linux je ready.
Rolling release na server pa samo kdor hoče težave. Prej ko slej... na server gre kvečjemu debian stable in gor samo varnostne popravke, hvala lepa, nasvidenje. No, to velja tudi za home usrja: if it ain't broken...
Mislim, da nas je večina uporabnikov Linuxa obh tej novici šokiranih in ne bomo mogli več spati, kaj šele uporabljati naših Opensuse, Debian, Puppy ali drugih distribucij. Sploh ker smo vsi zaskrbljeni zaradi napadalca na strežnik WordPress...
realnost je taka, da niti občutili ne bomo te problematike.
broken je upstream. Obstaja patch, ki je v repotih. Kje je problem?
Ko bo naslednji debian stable (ni še freeza) bo to tudi upstream popatchano. Torej: bi moralo biti tako.
Kje je problem?
Ni pojasnjeno kak nadzor se dobi? Root je disablan v določenih distrotih (razen če ga rebootajo pa grejo v recovery, kjer pa tudi izgubijo nadzor). Sudo brez gesla ne bo delal.
Pa pismu, a veste kolk je kode? v Win, OSx ali linux... pa to je normalno... in se zakrpa čao. In če je lokalno - where's the problem? Če je root je pa drugo: sploh če na serverju. Ni jasno.
