Već 8 godina... Lol

Znam da ce svi reci "svaki OS ima bugove" i tako to.

Medjutim za svih tih 8 godina niko nije otkrio tako gadan bug u "Open Source" Linux kernelu. Jos jedna prakticna potvrda da je teza OSS zealota o tome da je njihov kod "po dizajnu sigurniji jer je otvoren" najobicniji bull..



Ovo nije neki ultra-kompleksni bug, ovo je najobicnija programerska nemarnost - koju bi TREBALO da otkrije i daleko manje verziran developer.

Dakle, "Open Source - security by definition" je jos jednom pokazao svoje pravo lice.

Pa jos nisu stigli do sock_sendpage, to se cita polako i sa razumevanjem. Ne uci se napamet.

OK, radi se o bagu iz vremena pojave Windows XP OS-a. A da li si siguran da su svi XP-ovi bezbednosni propusti otkriveni do sada. Da li XP korisnici i danas instaliraju XP sigurnosne zakrpe?

@nedeljko
Mislim da je akcenat na jednom od glavnih argumenata linuksasa - "ima otvoren kod, mogu da radim sta hocu" :)

Masis poentu Nedeljko iako ti mase i hoce da ti udari u glavu direkno :)

8 godina je proslo - a niko od te silne "komune" nije uocio jedan krajnje trivijalan pocetnicki bag koji ima OGROMNE implikacije u oh-so-open Linux kernelu koga "gleda gomila ljudi i svako moze da se bavi otkrivanjem bugova".

I to pointerski bag u kernelu. Sramota.

Onaj Debian bug sa nesigurnim kljucevima koji je zijao 18 meseci je cak zahtevao osnovno znanje o kriptografiji da razumes sta treba a sta ne treba da se desi - ali OVO... sorry, za ovo NEMA opravdanja koje moze da ispegla tvrdnju o "sigurnijem otvorenom kodu".

A da... XP problemi.

XP je klijentski OS - problemi XP-a su problemi end-usera.

OVAJ problem, sa druge strane, nece kaciti Linux end-usere jer Linux end-useri nemaju javni SSH i naloge koje daju drugima tek tako. Medjutim gomila servera sa SSH i sl.. nalozima moze biti i te kako kompromitovana, pogotovu ako se ne apdejtuju automatski.

Koliko ima matorih Linux servera sa kernelima od 2.4 pa na gore, a tek koliko njih nema live update...

Svi oni sa mogucnoscu logovanja korisnika i izvrsenja bilo kojih procesa sa user-mode privilegijama imaju VELIKI problem.

Maši, maši, pa promaši...

Ama, vi mašite poentu! Niko ozbiljan nikada nije tvrdio da kačenje izvornog koda na net trebi sve bagove u trenutku uplouda poslednjeg bajta, već se radi o poređenju raznih pristupa sigurnosti. Dakle, ne o apsolutnoj, već relativnoj kategoriji. OK, trebalo je 8 godina da se uoči neki bag u oh-so-open Linux kernelu. Da li to znači da se svi sigurnosni bagovi u oh-so-corporative-commercial Windows-u uočavaju za <8 godina? Lako vam je da CEPETE o ciframa dok se ne uporede sa onim drugim.

Drugo, koji god bag da se otkrije, posle ispadne "Pa to je ono, kako nisam video". Što se debiLan baga tiče, da li je iko za tih 18 meseci pretrpeo ikakvu štetu od tog "security propusta". Čisto sumnjam. Nalazi matematičara o "nesigurnosti algoritama" se uglavnom svode na "Ovo je moguće razbiti efikasnije nego grubom silom, dakle ne za zilion godina, nego čak 20x manje". Sve to spada u domen važnih i korisnih razmatranja, ali ipak teorijskih. Dakle, to ipak ne spada u domen nečega što se može razbiti u realnom vremenu, već u domen nečega što je lakše razbiti nego što se mislilo.

http://www.linuxtoday.com/security/2008051601026SCDBNT

Debian SSH Key-Cracking Tools Released, Tips for Tightening

http://www.infoworld.com/d/mob...e-crack-debian-ubuntu-keys-467



A mogu da se zakunem da je na The Registeru bila vest o uspesnom koriscenju ovoga.

Fora je u tome da su napadi koristeci ovakve stvari sasvim drugaciji od tipicnih Windows trojan zajebancija - u slucaju Linux kernel vuln-ova (ili nesigurnih kljuceva) se gotovo uvek radi ili o privrednom kriminalu ili o ciljanom hakovanju nekog specificnog servera radi koristi - to ne rade neki php kiddies koji kace deface-ovane sajtove, vec se radi o daleko opasnijem kriminalu.

O tome definitivno neces citati puno u novinama - ali sam sasvim siguran da je dosta kompanija imalo direktan susret sa ovim problemima. SIgurno nisu odmah krenule u novine, vec su resile problem u tisini.

Pa ako vec tako postavljas stvari, da nije Linux Kernel open-source niko ne bi ni otkrio ovaj bug. Ovo chedo nije otkriveno fuzzing-om, vec analizom koda. Pitanje je sta sve chuchi u OS-X ili Windows kernelu. Btw, patch je objavljen nepunih sat vremena nakon objavljivanja bug-a.

Cinjenica je da ima Linux servera sa matorim kernelima, ali to je vec problem administracije. Ako vendor izbaci upgrade za softver, a administrator ga ne primeni to se zove lose odrzavanje servera. I toga ima svuda.

E to je to.
Kud se dedodse svi oni .... hakeri i freeminded ljudi koji tako povremeno prosvrljaju kroz kod i unapredjuju razne stvari. Usput vriste kako je apsolutni imperativ da se kao glavni OS u okviru vlada, vojske, svemirskih agencija uvede Linux - jel eto, otvorenog je koda, pa svako moze da vidi sta on radi.

Drugim recima, taj kod stvarno gleda 0.000001% korisnika Linuxa i eto, konacno se desilo da je neko to pronasao....

To sto je patch objavljen sat vremena samo pokazuje koliko je kritican bug. Fix za ovaj bug je vrlo prost - zato i nije bilo potrebno puno vremena da se opravi.

Sto se Windows kernela tice - vrlo sam siguran da takvih budalastina nema tamo, pricamo striktno o kernelu i kernel-mode kodu koji je pisao MSFT (naravno, nisam u zivotu imao vremena da gledam ceo windows kernel kod, ali uzevsi u obzir MSFT-ov SDL i vrlo strog code review, cisto sumnjam da bi se ovakva zloupotreba pointera tek tako provukla) - gotovo svi MSFT bugovi nisu u kernelu vec vise godina vec u drugim modulima sistema.

Sto se kernel-mode razvoja tice, mora postojati nulta tolerancija prema pointerskim greskama i kernel MORA dodatno da proverava parametre i vrsi validaciju velicine bafera i sl... prilikom prelaza iz uselanda u kernel-mod, jer bug u kernelu znaci i eskalaciju privilegija.

Secam se kada sam pisao svoj prvi Windows drajver da sam koristio DDK primere - i cudio se na koliko mesta postoji validacija svega - a sada mi je vrlo jasno zbog cega je tako. Userlandu se, jednostavno, ne sme verovati.

I neki iole ozbiljniji softver u osrednjim firmama sebi nebi dozvolio ovako nešto, ali eto... i SELinux (treba da ih je sramota tog prefiksa sad, ali nema veze) ima probleme ;)



Kakva zamena teza. Bravo. A ko je to pomenuo da se svi bagovi otkrivaju za manje od 8 god. ?
Ali se gore pomenuti, "klinački" bag garant ne provlači ovako dugo.



Izvini, u kom Windows Serveru se dogodio ovakav smešan propust?
Ako mi navedeš, ja povlačim reč.

E da, nema veze s temom, ali me mnogo zanima čemu to "debiLan" ili ".NjET" i tako to?
Ti to nikad nisi koristio Debian ili ga ne voliš iz nekog razloga ili je nešto drugo u pitanju...?

Pa, ako se i kod MS-a bagovi otkrivaju za 8+ godina, kakav je to onda protivargument za Linux? Gde je tu zamena teza?

Takođe, korisnika koji pretrpi štetu zabole da li je bag klinački ili starački i koliko je smešan - njemu je isto.

Eeeee,..... jadni ovi superkompovi. :(
tc, tc, tc...

Dobar si Nedeljko :)

Nikakav protivargument, ali pokazivanje/dokazivanje nečeg što nema veze s prvom Ivanovom porukom. Verovatno kako bi ovo opet bila yet another Linux/Windows bloat rasprava.



--
Nego, neke ispravke su se i ranije javile kako bi onemogućile mapiranje nulte stranice, ali se posle toga desio slučaj i sa pulseaudio-om. Nije baš redak problem eksploatacije dereferenciranja null pointera. Baš me čisto onako zanima koliko puta je pročešljan taj kod, a nije se uočio propust.
--



@musicmaster
Kakvi sad superkompovi? Mislim, ne vidim baš poentu u tom "tc, tc, tc".

Windows je imao bug preko "Mouse Pointera". Ne moze ovo gore da bude od toga ;) Ko ce da zakrpi masine koje 4 godine nisu tada bile azurirane ? OLOLOLO :)
Win2k WinXP ? Mislim da ovoga ima vise nego linuxa na trzistu. Client / Server nebitno je ja cu prkeo tog pointera da dodjem do nekog dokumenta.

Tolko o tome.

Ja ne vidim oko cega toliko buke Ivane. Ko radi taj i gresi zar ne? Ne znam imas li pojma o programianju i ako imas da li si nekada radio nesto veliko? Prosto je nemoguce otkriti sve logicke greske i kod mnogo prostijih stvari od OS-a ma koliko ljudi radilo na tome. U moru teksta shvatiti da si nesto logicki pogresio je gotovo ravno nuli osim u koliko sumnjas na neki propust pa ga trazis u odredjenom delu koda. Greske su moguce, pohvalno je sto niko nije imao problema zbog toga i sto je ispravka odmah izasla. Svaki os je imao i svi naredni ce imati bug-ove, a ako bas obozavas windows, secam ih se mnogo. Ovo je ona varijanta jedva cekam da ti nadjem gresku pa da vas pljujemo :)

Sticajem okolnosti, imam malo pojma o programiranju - nikada nisam vodio neki projekat velciine linux kernela (projekti sa trocifrenim brojem ljudi su moj maksimum za sada) ali sasvim dobro poznajem metodologiju razvoja ogromnih softverskih projekata sa sigurnosnim zahtevima...

Vidis, ovaj BUG je nesto vrlo atipicno za kernel jednog industrijskog operativnog sistema (sto Linux danas jeste). Microsoft ima SDL metodologiju, Solaris ima sigurno nesto ekvivalentno - a Linux? NULL pointeri u kernelu su rezultat ne-proveravanja validnosti pointera u ulasku u kernel mod sto je APSOLUTNO NEDOPUSTIVO danas.

Procitaj ovo:

http://msdn.microsoft.com/en-us/security/cc448177.aspx



Nemoguce je otkriti sve logicke greske u jednom OS-u - to se svi slazemo. Nemojmo otkrivati rupu na saksiji.

Medjutim moguce je vrlo efikasno spreciti ove greske implemntacijom metodologije programiranja koja zabranjuje koriscenje pointera koji dolaze iz userlanda u kernel-mode funkcijama bez predhodne provere validnosti. NULL pointeri su greska koja se >vrlo lako< sprecava uz pomoc obaveznog code-reviewa i jasnih pravila.

Ono sto jos vide bode oci je fakat da je ovakva idiotarija 8 godina cucala iako na Linux kernelu radi gomila ljudi i otvoren je na uvid svima.



Odakle ti ili bilo ko znate da niko nije imao problema? Kada je bug postao poznat postalo je samo jasno da gomile Linux kernela od 2001 do danas jesu ranjive na ovaj nacin.

Izvinite, A KAKO CE SE PATCHOVATI kerneli po raznim embedded uredjajima, recimo?



Samo napred - nadjite null-pointer eskalaciju privilegija u Windows Kernelu pa cu i ja da se pridruzim pljuvanju.

Ocigledno ne razumes koliko je ovo gadna greska i koliko je null-pointer eskalacija nesto sto je neprihvatljivo u kernel-modu.

Generaliziras, ovo samo pokazuje da je Linux development model cisti bullshit. Steta sta je upravo takav model najrasireniji OSS model.
Recimo, ovakvo nesto se nikad nije desilo BSDovima kojih ima poprilicno po internetu. Stvar je u tome sta je Linux kernel kod najobicnija k'upusara od starta, losa kopija, ma ne losa kopija nego improvizacija neceg drugog.

Poprilicno sam siguran da *BSD base ima magnitudu manje overall propusta od '93 pa na ovamo nego serverski Windowsi.
Sa takvom logikom bi dosli do zakljucka da OSS jeste security by definition.

Znaci dodjemo do zakljucka da niti open source niti closed source nisu security by definition, vec da sve ovisi o programerima koji stoje iza toga ;)
Kod opensourcea neki random developer moze primjetit i ispravit bug, ali moze i neki 'aker koji ce to iskoristit. Kod closedsourcea nije tako lako nac exploit nekome tko nema izvorni kod, ali isto tako moze postojat kriticni bug u XP-u godinama a da ga nitko nije nasao.

Sve je to relativno.



A u.

Edit : ***o te replacement k'upusare sa Linux OSom, odvali mi rjec iz konteksta :)

Nevena, poenta ovde nije u tome "uuu, pogresili ste, imate bug", vec u tome da vecina ljudi koji propagiraju Linux stalno govori kako je prednost Linux-a u brzom nalazenju i otklanjanju bug-ova jer je kod otvoren i to moze da uradi ko hoce. Medjutim, i pored otvorenosti koda i te mogucnosti, bug je postojao osam godina, i to u kernelu (za koji je logicno da bude najprovereniji).

Tacno.

Problem je sto je Linux postao sinonim za OSS uspeh.

Ocigledno Linuxu nedostaje rigorozniji model razvoja kernela - kad vec pomenuh Microsoft SDL. NULL pointer eskalacije u Kernelu su sramota, ali stvarno - sramota. Znam da BSDovi imaju daleko rigorozniji model razvoja od Linuxa (bas kao i Solaris i Windows, ali oni su komercijalni) i to je dokaz da sama otvorenost koda ne moze biti sinonim za podrazumevenu sigurnost - najvaznija komponenta sigurnosti je metodologija razvoja i njen odnos prema sigurnosnim propustima

Resenje protiv toga je vise nego jednostavno - samo je neophodno imati strogu metodologiju i mogucnosti provere koda, i to je ono gde problemi nastaju.

Lepo se ustanovi pravilo da sve funkcije koje su vrata izmedju userland-a i kernel moda MORAJU proveravati validnost pointera i verifikovati da ulazni i izlazni baferi imaju dovolju velicinu za predvidjenu operaciju. Plati se dobar tim koji radi obavezni code-review, u kome se radi fizicki pregled koda kao i stress-testing fuzzing metodom.

Jednostavno u kernel-modu mora vaziti opste pravilo: ne verovati nicemu sto dolazi iz userland-a i sto se moze menjati u userland-u. Znaci bilo kakvi pointeri, baferi, tabele sa pointerima na funkcije/pozive, itd... sve to mora biti provereno na ulazu u kernel mod.

Microsoft je imao tonu ovakvih problema (setimo se Russinovich-a koji je otkrio hrpu bagova u ntdll.dll koji je gatekeeper izmedju usermode API-ja i kernel moda) i posto je to pocelo ozbiljno da im ugrozava ugled OS-a, odlucili su da totalno promene nacin razvoja i da bukvalno raspisu kernel iznova sa SDL metodologijom.

Kao sto rekoh - poenta ovog blama je da je null-pointer eskalacija zvrjala u najkriticnijem delu operativnog sistema (kernel) 8 godina - iako taj Linux kernel koristi GOMILA firmi, gomila ljudi ga navodno pregledava, itd...

Pa kud baš na Ivana udari. Ovo ti tačno ono kad čovjek nema sreće. Baš sam skoro sa drugom komentarisao nešto, neki manje poznat teniser se napati kvalifikacijma npr. za Roland Garros, a onda u prvom kolu dobije Nadala. Pa znaš kakav je to baksuzluk. Tako i ti naleti na Ivana. Čuj njega da pitaš, ima li pojma o programiranju?!

U sustini jeste mada se sve pre ili kasnije ovde svede na pljuvanje win vs linux i slicno. Teoretski gledano zaista bi i trebalo da bude tako, imate mozga da zakljucite i sami, sto vise ljudi gleda, pre ce se otkriti neki problem ali sa druge strane ko gleda te kodove? 99,99999% korisnika linuxa nema veze sa programiranjem niti ih to zanima niti u krajnjem slucaju treba da ih zanima. Ostali su oni koji nesto znaju ali ih opet ne zanima da se zadubljuju u takve stvari, jednostavno mozda ce povrsno pogledati cisto da vide kako se to radi i ostaje neki ne znam koliko mali procenat ljudi koji ce ga zaista detaljno pogledati i eto, nasla se greska. Ne vidim nista skandalozno u tome, pronadjeno\ispravljeno. Treba naravno skrenuti paznju na to tipa da se zna, i treba da se zna ali ne bih im lupala klempe i govorila buuuuuuu na ulici :)

Skandalozno nije.

Sa druge strane, neozbiljno jeste - pogotovu ako se uzme u obzir da postoje drugi besplatni i otvoreni OS-ovi, kao sto su BSD varijacije kojima ovakva budalastina ipak ne bi mogla da se desi.

Linux ce postati zrtva sopstvene popularnosti zbog haoticnog modela razvoja i zelje da podrze sto vise stvari za sto krace vreme.

Neko bi zaista trebao da detaljno proceslja Linux kernel i da se potrudi da ovakve stvari nestanu.

Isti takav stil ima i M$.
Vazno je da izbacimo nesto prvi na trziste, nema veze sta ce i kako raditi bitno da smo prvi, da vucemo i stvaramo trendove, a posle .... peglacemo rupe. Ta filozofija je odavno poznata i cak ima i svoju ekonomsku vrednost iako bi se mogla i osporavati i velicati.

Microsoft je bar uveo SDL za njihov kernel, sam NT kernel je raspisan od nule SDL metodologijom, a oni propusti koji se vuku su od drugih komponenti i obicno datiraju od pre tog vremena jer ocigledno nisu imali racunicu da ceo OS raspisu od nule - zato ih je i zviznuo onaj kursorski fijasko, jer graficki podsistem Windowsa takodje trci u nultom prstenu.

Bilo bi jako skupo i tesko pisati ceo OS sa jakim zahtevima za robusnoscu koda - ali se to svakako moze traziti od jezgra operativnog sistema.

Time se zapravo ubija najveci deo kriticnih bagova - ne svi, naravno, u bilo kom OS-u gde drajveri mogu da trce u ring-0 modu Intel procesora bagovi u drajverima = sigurnosni problem, na zalost.

Medjutim, bagovi u samom kernelu su najopasniji i gotovo uvek podrazumevaju mogucnsot kompletnog preuzimanja sistema.

Sam kernel nije ogromna komponenta u odnosu na ceo OS i servise koje nudi.

Ocigledno - ljudi koji traze beskompromisnu sigurnost i otvoren kod ne bi trebalo da izabiraju Linux, vec BSD ili Solaris.

I sad ce linux kao da propadne zbog toga :DDD jest jest da...

Ko je rekao da ce da propadne?

Niko nije rekao da ce da propadne - ovako trivijalan a katastrofalan bag koji 8 godina zija u samom kernelu Linuxa samo govori o tome da je njihov haotican model razvoja sve samo ne "secure by design"

Svako moze da izvlaci kakve god hoce zakljucke, naravno. Samo kada sledeci put neki Linux "advokat" krene da trtla o sigurnosti njegovog "cheda" jer je "otvoren" bi trebao da ucuti :)

:)))) nemoj misliti da te ne volim iako te nekada uzmem na zub :)

Ovo gore mi je takodje bez osnova. Vi muski kao da ne znate da kontrolisete testosteron pa uvek vucete nesto na silu :)
To ne govori nista o tom konceptu niti o njegovoj zaista nikakvoj sigurnosti. To je jedna greska koja je isparvljena. Kladim se da ce njen rezultat biti sledeci... Sad ce veci broj onih koji nisu bili zainteresovani bas zagrizeno da pogledaju code jer mozda ima jos nesto tamo a svako voli da raskrinka noob-ove. I tako ce sam code postati jos jaci. Nekada su ljudi mislili da je zemlja ravna ploca a da ne odem predaleko i u skorije vreme je nauka svasta mislila pa je opovrgnuto i znaci li to da je nauka za seljake? Naravno da ne znaci. Svako mora prelezati svoje boginje pa makar i posle 8 godina. To je veliki propust ali samo propust i vrlo lako se moze desiti da je on sada kada je ispravljena ta decija greska sigurniji od bilo kog os-a. Mozda nema vise gresaka, ko zna, moguce, a moguce da ih ima jos 1000. U svakom slucaju nisa nije dokazano osim da je sada sigurniji nego pre mesec dana.

Jeste pokazano :)
Pokazano je to da sigurnost ne zavisi od otvorenosti koda a sto zapravo tvrde Linux pobornici.

Ako cemo da bas da preciziramo, jedino sto je pokazano, jeste da, apsolutna i stopostotna sigurnost ne zavisi od otvorenosti koda. Sto niko ionako nije tvrdio.

Inace, ja nista ne tvrdim nemojte da me gnjavite sa odgovorima :D
Osim ovoga gore :D

A sa čim ima veze originalni post "otkriven je bag u Linux kernelu star 8 ljeta"? Ako je to normalno za sve modele razvoja, onda to nije nikakva vest za advocacy.



Tačno, ozbiljni pobornici OSS modela su eventualno trvdili da je taj model bolji od klasičnog na polju bezbednosti, a ne da upload poslednjeg bajta source-a trebi sve sigurnosne propuste, koji su se eventualno našli u njemu. Dakle, radi se o relativnoj, a ne apsolutnoj kategoriji.

Ne, radi se o najobicnijem FUD-u, posto ne postoji ni jedna kredibilna studija koja dokazuje da je "otvoreni kod" sigurniji od zatvorenog.

I taj FUD polako pocinje da biva smesan u fazonu "car je go" :)

Boze ljudi oko cega se vi raspravljate. Sta je ovde tolko haoticno odjednom ? Pravite problem kao da je Y2k :)

I gde si nasao embedded uredjaje bas :) Daj jedan koji bi stvarno bio problem cisto da vidim kolko je to opasno.

Zavisi samo vi to bas ne usporedjujete pravedno. Reci da sigurnost ne ovisi o otvorenosti koda je sama ludost. Koliko moze doprinjeti moze i stetjeti i previse je parametara koji odredjuju sta ce od toga dvoje biti od strucnoga znanja do moralnih normi, sto nitko nije uzeo u obzir. Takodjer cijelu filozofiju razvoja nazvati losom radi jednog epxploita jednog projekta nije bas logicno. Odrediti sve parametre onda kritizirati. Sta je s drugim projektima koji koriste istu metodu?

Koristim linux, a takve rupe popraviti ne mogu jer je moje znanje programiranja vrlo malo do nimalo tako da bi volio vidjeti neki konkratni broj koliko ljudi kernel kod bas izcitava? I ako ce vec biti usporedjivanja taj broj usporediti s brojem M$ developera, takodjer usporediti i financije itd., jer je ipak vecini linux hobi dok je drugima to primaran posao.

Sto se tice tog explota nisam strucan pa neka mi neko objasni koliko je u biti tesko ga naci i koliko ga je tesko koristiti? 8 godina je tu da ga je neko i zloupotrebio ranije bi se otkrilo; takodjer kolika je steta nanjeta tom rupom do sada? Dali se moze lagano remote iskorsititi? Ako se ne moze cemu tolika buka kada postoje rupe u mnogo visim stvarima od krenela koje dopustaju full control nad racunalom?

Jos me zanima koliko tocno treba vremena proci za krenel rupu da postane sramota? Vidim da se dize buka oko ovoga na netu koja mi je nejasna pa me zanima....

Recimo slot mašina koja radi pod linuxom, a koja isplaćuje stvaran novac... Pravi način da uštediš 50 evra, na uređaju koji košta 5000+ evra, tako što ćeš uštedeti na Windows licenci... A da, uz put, linux je i mnogo sigurniji i brži i bolji od windowsa...

Pa i nije bas tako.

Pricamo o "Enterprise Linuxu" - dakle, ima gomila velikih firmi koje stoje iza Linuxa i koje prodaju ne tako jeftino kojekakve solucije bazirane na njemu - IBM, RedHat (koliko znam njih ne kaci ova glupost), Novell, itd...

Kao i ona budalastina na Debianu (dobro to defininitivno nije poslovna distribucija) kada je generisao predvidljive SSL/SSH kljuceve godinu ipo dana - razne institucije uzimaju Linux za neke back-end poslove zbog navodne sigurnosti.

Dimkovicu, u njegovom postu je bilo jos pitanja... :)

Kojih pitanja?

Gde da nadje exploit?

http://archives.neohapsis.com/...lldisclosure/2009-08/0174.html



^ ovo je samo deo koda koji ce napraviti s*****, autor naravno ne daje i kod koji bi ubacio neki maliciozni shellcode, ali svaki iole obrazovaniji haker to zna da uradi, a ne sumnjam da ce uskoro biti dostupni i kompletni "instant" programi koji rade neku akciju, recimo lansiraju bash kao root.

Koliko je opasan?

Pa, eto - svako ko ima remote pristup racunaru i mogucnost da izvrsava procese kao obican user moze dobiti privilegije root-a.

To ukljucuje:

- Komercijalne Linux hosting servise koji nude SSH, ili neki drugi nacin pristupa gde je moguce izvrsiti proces
- Korisnike koji imaju SSH pristup nekom serveru, ili neki drugi nacin pristupa gde je moguce izvrsiti proces
- Embedded NAS uredjaje koji nude i shell pristup istima
- Sve Linux masine gde postoji mogucnost lokalnog logovanja i izvrsavanja programa (po firmama, recimo)



NULL pointer eskalacija u kernelu je uvek sramota.

:)

Salu na stranu, to sto je kod otvoren za sve ne znaci nuzno da neki
propust nece da se podkrade, pa i ovako veliki kao sto je ovaj.
Svakako se slazem da je najbitnije koliko se sistematicno i metodicno
pristupa testiranju nekog koda pre pustanja "u etar", bilo da je on closed
ili open source. Open source SVAKAKO pomaze sigurnosti, ali samo
potencijalno, ne nuzno.

No i pored ovoga, mi i dalje cekamo da na nekom hack contest-u windows izdrzi duze od linux-a ;)

OK, budući da si ti pokretač teme, šta potvrđuje ovaj nalaz? Da je car go? Pa, ne baš... to ne pokazuje ama baš ništa bez poređenja sa drugim pristupima. Zapravo, pokazuje da ne postoji apsolutna sigurnost. Pa, šta. Da li je iko tvrdio da postoji?



Jesi li siguran da su predvidljivi? Da li bi mogao da ih predvidiš u realnom vremenu i da nam to pokažeš? Šta misliš, da MS nije pravio takve propuste?

http://news.techworld.com/secu...p-random-number-generator-bug/

Štaviše, ovaj bag je zjapio mnogo duže od 18 meseci. Šta to onda govori o pristupima bezbednosti?

E moj Nedeljko - taj MS flaw je ostao samo u labu tih likova, a Debian:

http://www.cr0.org/progs/sshfun/




Ma da... ista stvar, skroz :)

Sto se pristupa bezbednosti tice - i sam znas da je Microsoft tek poceo ozbiljno da se bavi tim sa XPSP2/WinServer 2003 kernelima.

Izgleda da je glavni izgovor korisnika linuksa:
Logicno razmisljajuci dosao sam do sledeceg zakljucka: Posto svako ima pristup linux izvornom kodu, svako ko se razume moze da nadje neki bug i da ga iskoristi na ko zna koji nacin. Dok je to kod m$-a malo teze... Mislite da niko nije nasao ovaj bug ranije i koristio ga ko zna kako?

Tako je. Ne vidim razlog zasto OSS model ne bi bio rigorozan (prema "cathedral" modelu), gdje, kao kod BSDa postoje raznorazne grupe ljudi vodjene officerima koje imaju razlicite jasno definirane uloge u development cycle-u. Isto kao i kod Windowsa i bilo kojeg closed-source softvera, s tim da ovdje imas pravo vidjet kompletan kod na CVSu, prepravit nesto, nadogradit...ali takvo nesto se rigorozno kontrolira, da se ne bi desilo sta se desilo Debianovim developerima sa njihovim famoznim OpenSSH patchom.

Inace, za sve Linuxase, evo kako to provjereno radi;

http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/

I jos je usput fino profesionalno dokumentirano, kao i sve u tom sistemu :)



Problem je sta je sam Linux od starta pisan po pazaru, i sta sad treba mjeseca i mjeseca da se napravi cjelokupni code audit.
Jos jedan problem lezi u razdvojenom development cycleu kernela i userlanda. Jednostavno userland provajda sve korisnicke servise prema kernelu, i mnogo je lakse nac i ispravit bug ako je razvoj sinkhroniziran. Svi kernel bug-ovi se manifestiraju kroz userland programe i njihovo koristenje sistemskih poziva, I/O streamova i ostalog prema kernelu.

Kad se nesto radi od starta kako treba, onda nije tesko; jedan od tisucu primjera je implementacija strlcpy funkcije na BSDovima koja je copy-safe, automatski nul-terminira i nema buffer overflowa sa njom. Naravno, prominentne Linux glave i dalje imaju svoje misljenje;



Znaci, gore je ako alociras 5 charova i gurnes "elitesecurity" unutra, i dobijes samo "elite", pa ces to kad tad primjetit negdje u programu i ispravit, nego ako pointer pokazuje na kompletan "elitesecurity" block koji je krivo alociran. Bravo, high-five.



Prije cu se kladit na Windowse ako su oba sistema apdejtana do kraja i nemaju nikakav dodatni servisni paket po sebi (web, IRC, im-ovi, ftp, mail...).

Za dobrim se konjem prašina diže!

@Ivan Dimkovic

Šta, osporavaš da se CPAHjA sa generatorima pseudoslučajnih brojeva dešavaju velikima ili ja možda mašim poentu. Takođe, da li je iko pretrpeo ikakvu štetu od debiLan-ovog baga? Postoji li način da se ključevi zaista razbiju u realnom vremenu ili je taj bag ipak samo u domenu teorije?

@Milos911

Da li mi windows omogućava da odletim na Mars? Ne? Izem ti takav OS.

Da, o kvalitetu rešenja se može diskutovati samo sa aspekta poređenja sa drugim rešenjima. Sve ostalo je spin.

Pa, kladi se i javi kako si prošao sa opkladom.

Cujes...manji je broj 0-daya za bazni Windows sistem nego za ekvivalent Linuxa. Mozda ne dobijem okladu, al statistika je na mojoj strani ;)

Baza random sekvence je, ako me memorija dobro sjeca, bila process ID trenutne instance OpenSSH/SSL generatora. Inace se za takve stvari uzme process ID, trenutni CPU usage, datum, vrijeme, i ostale proizvoljne stvari koje na kraju daju nekakav broj (long) kojega je tesko saznat osim ako netko ne zna tocnu situaciju sa masinom u toj, skoro pa kvanti vremena, sta je sansa od 0.0000000001%

Ovako, PID je unsigned integer sta bi znacilo da je baza random sekvence broj od 0-65535.

Znaci da je dovoljno maksimum 65535 kvazi brute force / generacijskih pokusaja da se dodje do privatnog dijela kljuca, sta je ravno katastrofi.

Sta se tice stete, ne znam koliko je $ izgubljeno direktnim hakiranjem (vjerovatno ne puno, jer nisam cuo nijedan zesci slucaj), medjutim evo ti primjer; nakon saznanja za propust, prosli smo kroz 40tak Debian servera koje imamo (kod klijenata), i troje ljudi je izgubilo cijeli radni dan da se regeneriraju certifikati. Nakon toga smo izgubili iduci cijeli radni dan da korisnicima podjelimo certifikate i zamjenimo postojece na njihovim klijentskim stanicama.

Ako kontamo koliko nasa firma naplacuje rad naseg odjela prema klijentima, dolazimo do poprilicne cetveroznamenkaste cifre eura gubitka u vremenu.

Sad zamisli nekog ogromnog enterprise ISVa sa stotinama takvih sistema.

Ako mislis na Debian bug - ocigledno je moguce razbiti kljuceve za oko pola minuta na iole jacoj kucnoj masini.

Da li je neko pretrpeo ozbiljnu stetu od Debian baga? Ne znam, ti mi reci - cenim da kompanije kojima su serveri hakovani nece bas veselo pevati o tome, jerbo su same sebi zakuvale corbu "sigurnim" resenjem (da je u pitanju MS, pala bi i neka tuzbica - ovako, mozes samo da pojedes onaj CD sa narezanim Linuxom od muke ;-)

http://www.theregister.co.uk/2008/08/27/ssh_key_attacks_warning/

Znači, seme se inicijalizuje samo na osnovu PID-a tako da ima najviše 65536 mogućnosti za početnu vrednost semena. Jesam li dobro razumeo? Au, vala ja nisam stručnjak za kriptografiju, ali ovakvu grešku ne bih napravio.

No, ja ne mislim ni da su 32 bita dovoljna širina semena (samim tim je to premalo mogućnosti za početnu vrednost semena). Čemu onda povećavanje broja bitova za ključ, ako je dovoljno "samo" 4 milijarde pokušaja? Ja za kriptografiju ne bih koristio algoritam sa semenima širine <64 bita, a neki algoritmi imaju semena sa širinom koja ide na kilobajte, kao što je MT19937 (šta ćeš, period dužine > 2^n-1 nije moguće postići bez semena širine najmanje n bitova). Naravno, za inicijalizator se takođe treba pobrinuti da ima dovoljan broj mogućnosti.

Pa, dobro, debiLan je ipak jedna od distribucija koje nisu za takvu ozbiljnu upotrebu. Ne znam ko to ozbiljno koristi. Ako hoćeš nešto ozbiljno, onda uzmi nešto enterprise. Ovako, oslanjanje na distribuciju koja se hvali time da nema ništa komercijalno, pa ni podršku nije ozbiljno.



Jesi li siguran u to. Da li je to provereno u sudskoj praksi?

Vezano za te random generatore, nekad je i previd u samom algoritmu dovoljan da zajebe stvar.. Evo kako to izgleda u praksi:

"How We Learned to Cheat at Online Poker"
http://www.cigital.com/papers/download/developer_gambling.php

Al ti je logika, bas i ne mora da se vidi ms kod nadju oni te bugove i bez toga i to mnogo lakse... ah racunari sto ti je to cudo jedno