The saga continues

Just read and learn, penguins: KLIK

Kaksna saga? A ne bi bilo enkrat za spremembo kul napisati v naslov teme tisto o cemer naj bi tema govorila?

Sej ne recem, da tisto odkritje ni zanimivo... z akademskega stalisca. V bistvu gre za information leakage s katerim dobis podatke o izgledu naslovnega prostora dolocenega procesa. Cenzuriranje /proc/pid/maps ni dovolj (ce imas se /proc/pid/stat in /proc/pid/wchan). Drugo je timing attack s katerim zarad napake v algoritmu z veliko verjetnostjo dobis isto.

Amapk samo po sebi je to cisto neuporabno. Uporabno je sele, ker lahko s tem znanjem teoreticno zaobides ASRL. In tudi to ti nic ne koristi. Zaobiti ASLR hoces sele, ce je recimo sklad neizvrsljiv in ne mores svoje shell kode pretihotapiti kot podatke v program, temvec hoces recimo narediti return-into-libc napad. Drugo je seveda, da mora imeti program ranljivost, ki ti sploh omogoca izvajanje kode.

Torej zelo veliko "ce"-jev, preden je odkritje lahko uporabljeno v praksi. Ne recem, da ne bo, ampak kakor hitro imas program s tako ranljivostjo si tako ali tako screwed up. Moras racunati na to, da te lahko kadarkoli nekdo owna, ne pa da se zanasas na razne varnostne mehanizme, ki ze po definiciji ne morejo biti 100% tako kot koda zaradi katere je sploh prislo do problema. Oboje skupaj je bolj varno samo zaradi tega ker je zascitni mehanizem razmeroma enostavna koda, ki varuje bolj kompleksno kodo (manj lukenj v vecjem kosu odtehta morebitne luknje v manjsem).

Po analogiji - ce delas cirkuske akrobacije na visini, moras biti vedno pripravljen na to, da pades (in znati pravilno pasti brez da se hudo poskodujes) ne pa da gres povsod napenjati varnostne mreze in se potem zanasas le na tisto. Je pa jasno tudi mreza v redu, ker si potem ne zlomis vsakic roke.

denial: Sem prebral tudi tvoj drug post in kernelbof, brez skrbi. Tisto je bil memory corruption v kernelu, kar je precej kriticno. Je pa moral teci kaksen SCTP daemon, tako da vseeno ni imelo nekega vecjega impacta. Avtor se je potrudil, da je napisal remote exploit za to in s tem dokazal, da so ljudje napako (morda celo namerno?) podcenjevali kot samo nacin za izvajanje DoS napada.

Tole tukaj je pa v vsakem primeru samo napaka v zascitnem mehanizmu (tudi teoreticno ni mogoce tega drugace izrabiti).
Torej mora biti nujno prisotna se neka druga huda napaka, ki omogoca izvajanje poljubnih strojnih ukazev, da tole lahko pride v igro. Vse skupaj samo dokazuje, da so povsod mozne napake in se ni pametno zanasati samo na non-exec stack, ASLR in podobne mehanizme, ampak je treba tudi cim prej upgradati ranljiv program.

Kernelbof je v bistvu prakticna izraba nekega odkritja, medtem ko je tole cista teorija, ki bo morda kdaj prisla hekerjem.
Napaka sama po sebi ni tako kriticna kot jo hoces prikazati (samo s tem ne mores ownati masine).

Lepo da se trudiš, vendar lahko verjameš, da vem kaj je to ASLR. Nikjer tudi nisem napisal, da lahko rootneš mašino izključno zaradi teh ASLR bugov, torej ne trdi nekaj kar ne drži.

Verjamem, da ves. Tega nisem pisal zaradi tebe, ampak zaradi koga drugega, ki bo prebral "ASLR ima bug" in potem hotel disablati ASLR, da ga ne bi kdo slucajno ownal.

Ocena o kriticnosti napake je, vsaj upam da, bolj objektivna kot subjektivna. Brez raznih anti-linux biasov oz. predpostavk o tem, da je napaka v necem, kar je misljeno za varovanje bolj kriticna kot podobna napaka v drugem programu. V kolikor se ljudje zanasajo samo na ASLR je to njihov problem.

Ce realno pogledas: kaj ti napaka omogoca? Pridobis nekriticne podatke o sistemu. Primerljivo s tem, da ti streznik v bannerju oznani tocno verzijo in verzijo OS-a na katerem tece. Tudi to je prakticno neuporabno, a vseeno podatke nekdo lahko izrabi za lazji vdor v ranljiv sistem. No mogoce so podatki malo bolj pomembni, ampak s kaksnim verbose sporocilom o napaki na slabo skonfiguriranem strezniku se pa to ne more primerjati.

Obstaja na stotine streznikov, ki v privzeti konfiguraciji oznanjajo take podatke, pa vseeno ne zganjas zaradi njih panike. Medtem ko napaka v memcachedb, ki tudi zavesto oznanja podatke o pomnilniku procesa, predstavlja kriticno ranljivost?

Ok tisto drugo je bolj komplicirano, ampak rezultat pa ni nic drugacen. Se vedno dobis podatke, ki niso tajni. Jasno v povezavi s kaksno drugo napako, to lahko pomeni razliko med uspesnim in neuspesnim vdorom, ampak samo po sebi ima pa to IMHO se vedno le akademsko vrednost.

Mac OS X recimo sploh se nima popolnoma delujocega ASLR. Torej bi bilo prej treba opozoriti na to, kot pa na ranljivost v implementaciji ASLR na drugem OS. Je pa jasno to drugo bolj zanimivo branje. Saj je cisto prav, da se zadeva oznani, navsezadnje lahko napako v ASLR kdo ze izkorisca v povezavi s cim drugim, ampak ne zdi se mi pa prav, da se okrog tega dela tak hype.

Če misliš, da je moje poslanstvo pljuvanje čez Linux: v enem postu sem prilimal link do intervjuja s Charlie Millerjem, ki je povedal kar nekaj krepkih o Mac OS X implementaciji ASLR-ja. Objavil sem tudi več postov o 0-day bugih v Firefox-u, Adobe Reader-ju, tudi v Winsih...

Hype? Kakšen hype neki, če posta ne bi objavil, bi le redko kdo sploh slišal za bug. Nisem zasledil, da je bilo to objavljeno na kakšni geek news strani. Tudi SCTP bug ne.

Ve se kje je srž problema "kernel team vs security researchers". Kratko bodo itak potegnili uporabniki.

Banner announcement is not a bug, it'a a feature :) Nekaj kar je splošno znano. ASLR ne predvideva information leakage.

... ki bo prebral "ASLR ima bug" in potem hotel disablati ASLR, da ga ne bi kdo slucajno ownal.

Ah, daj no, Linux userji so pa ja eksperti in razturajo zadevo.