[es] - Bug exposes eight years of Linux kernel

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16687
*.dip.t-dialin.net.

+7177 Profil

Re: Bug exposes eight years of Linux kernel

^{15.08.2009. u 22:14 - pre 179 meseci}

Kojih pitanja?

Gde da nadje exploit?

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

Citat:

This issue is easily exploitable for local privilege escalation. In order to
exploit this, an attacker would create a mapping at address zero containing
code to be executed with privileges of the kernel, and then trigger a
vulnerable operation using a sequence like this:

Code:

/* ... */
    int fdin = mkstemp(template);
    int fdout = socket(PF_PPPOX, SOCK_DGRAM, 0);

    unlink(template);

    ftruncate(fdin, PAGE_SIZE);

    sendfile(fdout, fdin, NULL, PAGE_SIZE);
/* ... */

Please note, sendfile() is just one of many ways to cause a sendpage
operation on a socket.

^ 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)

Citat:

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....

NULL pointer eskalacija u kernelu je uvek sramota.

DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey

Odgovor na temu

Srđan Pavlović
Specijalna Edukacija i Rehabilitacija MNRO
Vojvodina, Bačka Palanka

Član broj: 139340
Poruke: 5571
*.static.isp.telekom.rs.

Sajt: www.oligofrenolog.com

+382 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 08:38 - pre 179 meseci}

:)

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 ;)

oligofrenolog

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
195.222.97.*

+2790 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 09:08 - pre 179 meseci}

Citat:

Ivan Dimkovic: 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" :)

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?

Citat:

Ivan Dimkovic: 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.

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?

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16687
*.dip.t-dialin.net.

+7177 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 11:50 - pre 179 meseci}

Citat:

Nedeljko
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?

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

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

Citat:

*

ssh_kex_keygen: a tool to retrieve the Diffie-Hellman session key in a SSH conversation capture involving at least one OpenSSH running with a vulnerable OpenSSL. Key recovery will take half a minute on decent hardware.

Be aware that this tool does'nt parse a pcap file, nor does it decipher the traffic for you, it has to be used in a higher-level program such as ssh_decoder in order to be useful.
*

ssh_decoder: a tool to decipher a ssh session from a pcap file (uses ssh_kex_keygen). This will allow you to retrieve passwords or public SSH keys used for authentication that may be vulnerable and to read older SSH traffic.
*

bfssh: a multi-threaded tool written in C to retrieve weak keys in authorized_keys files on a remote machine. It'll test for all possible keys for a given architecture in less than five minutes on a decent network. You'll need a vulnerable libssl/libcrypto and libssh to compile/use it.

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.

Odgovor na temu

Milos911
Serbia

Član broj: 219127
Poruke: 1230
*.telenor.co.yu.

+303 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 12:35 - pre 179 meseci}

Citat:

Nedeljko: Šta misliš, da MS nije pravio takve propuste?

Izgleda da je glavni izgovor korisnika linuksa:

Citat:

To ne radi ni na windowsu. Windows je imao iste greske, i ko zna kakve jos ima

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?

Odgovor na temu

z@re
Zarko Bulatovic
Split

Član broj: 29849
Poruke: 443
*.st.cable.xnet.hr.

+25 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 15:08 - pre 179 meseci}

Citat:

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

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 :)

Citat:

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...

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;

Citat:

Drepper argues that strlcpy and strlcat make truncation errors easier for a programmer to ignore and thus can introduce more bugs than they remove

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.

Citat:

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

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...).

_{Q: HSP56 Micromodem nece da radi kompjuter ga prepozna a kad treba da se konektujem nece ne daje ni znaka zivota. u cemu je problem.

A: Crko mozda od grmljavine mozda od spanaca. Uglavnom baci ga u WC solju jako povuci vodu. Skupi 5e i uzmi drugi i ne postuj temu na pogresno mesto.}

Odgovor na temu

BiF

Član broj: 39763
Poruke: 90
89.216.59.*

Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 15:37 - pre 179 meseci}

Za dobrim se konjem prašina diže!

Nijedan nepušač još nije preživeo.

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
93.87.130.*

+2790 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 15:44 - pre 179 meseci}

@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.

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
93.87.130.*

+2790 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 15:46 - pre 179 meseci}

Citat:

z@re: 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...).

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

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

z@re
Zarko Bulatovic
Split

Član broj: 29849
Poruke: 443
94.253.241.*

+25 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 16:24 - pre 179 meseci}

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

Odgovor na temu

z@re
Zarko Bulatovic
Split

Član broj: 29849
Poruke: 443
94.253.241.*

+25 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 16:34 - pre 179 meseci}

Citat:

Š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?

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.

Odgovor na temu

Ivan Dimkovic

Administrator
Član broj: 13
Poruke: 16687
*.dip.t-dialin.net.

+7177 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 16:35 - pre 179 meseci}

Citat:

Nedeljko
Š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?

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/

Citat:

Attacks in the wild are under way against Linux systems with compromised SSH keys, the US Computer Emergency Readiness Team is warning.

The attacks appear to use stolen SSH keys to take hold of a targeted machine and then gain root access by exploiting weaknesses in the kernel. The attacks then install a rootkit known as Phalanx2, which scours the newly infected system for additional SSH keys. There's a viral aspect to this attack. As new SSH keys are stolen, new machines are potentially vulnerable to attack.

The CERT advisory makes no mention of the flaw in the Debian random number generator, but that's most likely the starting point for the attack. The flaw caused SSL keys generated for more than a year to be so predictable that they could be guessed in a matter of hours. Debian fixed the flaw in May.

Once a Linux server using a weak key is identified and rooted, it quickly gives up the keys it uses to connect to other servers. Even if these new keys aren't vulnerable to the Debian debacle, attackers can potentially use them to access the servers that use them if both the private and public parts of the key are included. Additionally, attackers can identify other servers that have connected to the infected machine recently, information that may enable additional breaches.

Phalanx2 is a derivative of a rootkit known as Phalanx. According to Packet Storm, Phalanx is a self-injecting kernel rootkit designed for the Linux 2.6 branch that hides files, processes and sockets and includes tools for sniffing a tty program and connecting to it with a backdoor. Phalanx2 is been updated to systematically steal SSH keys.

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
195.222.97.*

+2790 Profil

Re: Bug exposes eight years of Linux kernel

^{16.08.2009. u 18:42 - pre 179 meseci}

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.

Citat:

Ivan Dimkovic: da je u pitanju MS, pala bi i neka tuzbica

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

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu