Nije neočekivano od Dimkovića.
Mogao je bar da se potrudi pa da pročita i tamošnje komentare, evo jednog bitnog:



Ukratko, potrebno je imati root pristup linuxu da bi se rootkitom moglo naškoditi, a ko ima root pristup, verovatno može i drugačije da sredi sistem.

Ne znam ja, ja sam samo preneo vest.. a root nalog na Linuxu videh vise puta na onom Ubuntu-u - cak je i zatamnio ekran i pitao za root lozinku vise puta dok sam pokusavao da napravim Moblin image...

Zanimljivo, reko bih da sam to video negde drugde hihihi :)

bilo je i prije rootkitova za linux, u oovme je posebnost ocito sto dobijes podrsku open source komune, sad ako ce neko vjerovat oss komuni da ce mu rootkit ostat neoprimjetan to je drugo pitanje.

http://en.wikipedia.org/wiki/Rootkit

hmm, cini mi se da se neko ovde zbunjuje oko necega , baci te pogled na wiki link koji je dao srdjan

znaci , da bi uopste iskoristio rootkit za nesto , prvo moras da dobijes pristup bilo komkorisnickom nalogu
pa da zatim dobijes root pristup , pa da onda instaliras rootkit

isto kad kad bi na windowsu redimo , lupam, kao administrator ukucao format c:

znaci, rootkit , NIJEDAN rootkit , ne iskoriscava propust u sigurnosti sistema , vec se koristi za skrivanje napadaca NAKON iskoriscavanja nekog sigurnosnog propusta




Taj IMMUNITY rootkit nije nista posebno ,

cak bih ga pre nazvao proof of concept

mood-nt , koji mozete da skinete sa packetstorma recimo , ima mnogo vise funkcionalnosti
a radi na upravo isti nacin kao DR rootkit koji je Immunity upravo objavio
a antifork ekipa ga je objavila pre dve godine ako se ne varam

u prethodnom phracku je bio tekst koji je objasnjavao kako ovo funkcionise

inace, dzabe je sto je javni kad ne moze da se sakrije kako treba bas zbog toga sto je javni

a za tehnicku podrsku , heh , morao bi malcice vise da platis Dave-u Aitel-u za Canvas licencu


@srdjan

pa ima i na srskom

http://www.phearless.org/istorija/razno/rootkits.txt

sacuvan je , iako ga je izbacio iz tog izdanja :)



_{[Ovu poruku je menjao EArthquake dana 06.09.2008. u 13:34 GMT+1]}

Kada već govorimo o sigurnosti, nije mi jasno kako OS može da dozvoli direktan pristup disku, zaobilazeći FS, a to dozvoljavaju i Linux i Windows i to se smatra nečim potpuno legalnim. Kao, neće raditi neki programi bez toga. I onda se cepe o bezbednosti.

nisam siguran na sta konkretno mislis
pod pristupom disku zaobilazeci FS

mislim , iz kernela u svakom sistemu mozes da radis gotovo bilo sta , ali ti za to trebaju odredjene privilegije

iz userspace-a , ne bas

Recimo na Windows aplikaciju koja se oslanja na BIOS ili na gledanje diska kao na fajl u /dev direktorijumu pod Linux-om itd.

Ne mozes da zoves BIOS funkcije jer i Linux i Windows rade u 32-bitnom (64-bitnom) zasticenom modu.

Tvoj user-mode proces ce samo izazvati sopstveni krah kada bi hteo da pozoves neki real-mode interapt ili da pozoves real-mode f-ju u BIOS-u.

U NT kernelu od verzije 6 pa na dalje, cak ni aplikacija sa root privilegijama ne mogu da pristupe dumpu fizicke memorije, pa ne mozes cak da stignes ni do "vidjenja" BIOS memorije - a i da je vidis (kao sto mozes na Linuxu ili u XP-u) opet ne mozes nista sa njom, jer su to real-mode rutine.

Znaci otkrili su nacin da sakriju proces... a taj proces mora root da pokrene.

Ja koristim linux (medju ostalog) bas zato sto mogu da radim sve sta hocu... a ne da me sistem ogranicava.

Ako je aplikacija na root nivou, zasto ne bi smela da vidi mem dump? ili treba za to neki superroot? Vazno je samo da OS ne dozvoljava programima da stignu do root nivoa, ako user to explicitno ne zeli. Za sve ostale primere vazi PEBKAC ( http://en.wikipedia.org/wiki/PEBKAC )

Mene zapravo zanima pristup fizickom dampu diska. To je na Linux-u moguce, mislim i bez root privilegija, kako za citanje tako i za pisanje. Kako onda rade programi za upravljanje particijama?

Usermode procesi pod root nalogom nemaju nikakav razlog da pristupaju fizickoj memoriji, jer oni i ovako i onako NE RADE sa fizickom memorijom vec sa virtuelnom, pa layout u fizickoj memoriji nema smisla - osim ako ne trce u kontekstu usera sa debugging privilegijama gde je neophodno ocitavati neke fizicke adrese.

Sto se tice fizickog pristupa disku, u XP-u si mogao pristupiti bilo kojem kao Admin, dok u Visti mozes sledece:

1. Ne-sistemskim diskovima mozes fizicki pristupiti i iz userlanda kao admin-mode proces, ali samo ako ih dismountujes prvo (znaci, ne mozes pristupiti aktivnom disku) - tako radi CHKDSK
2. Sistemskom disku mozes pristupiti iskljucivo iz Ringa 0 - tj. iz drajvera

Ideja je sasvim OK - svi sistemski alati ce i ovako i onako imati Ring 0 komponentu za pisanje, sto zahteva sertifikaciju drajvera preko WHQL, sto smanjuje mogucnost malware-a koji upisuje nesto po sistemskom disku - 32-bitna Vista/Server 2008 dozvoljavaju instalaciju ne-WHQL drajvera, dok na 64-bitnim OS-ovima to nije moguce, osim ako ce ceo OS ne pokrene u debug modu sa disable-ovanjem citanja potpisa.

@mulaz,

U pravu si, a i nisi u pravu - sve zavisi iz kog konteksta gledas. Po VMS filozofiji, Root nije Superuser (postoji i nalog "iznad" koji ima sve privilegije), dok po Unix filozofiji root je superuser, i trebao bi da ima prava da radi ama bas sve na sistemu, ukljucujuci i pristup fizickoj memoriji i diskovima na sektorskom nivou.

Windows NT je modeliran po VMS-u a ne po Unixu (nasledje Davida Cutler-a) - i zato ovakva ogranicenja imaju smisla jer su deo VMS filozofije, dok Linux jeste modeliran po Unixu, i njegov root nalog ima "jace" privilegije od Windows-a i VMS-a. Ako malo bolje razmislis, davanjem svega Root nalogu se potpuno anulira prednost 386+ CPU-a gde sistemski procesi trce izolovani od user-mode procesa, jer Root proces teoretski moze da "pokvari" i deo memorije koji pripada sistemskom procesu uz pomoc pisanja po fizickoj memoriji...

Nema nikakvog razloga da se raspravljamo o tome - jer su oba nacina tretiranja Root naloga nesto sto je primenjeno u industriji. Meni licno vise ima smisla VMS pristup, tebi ima vise smisla Unix pristup - i to je to, nije da je jedan sigurno bolji od drugog, vec zavisi od same primene.

programi za upravljanje particijama rade tako sto su SUID root ,

tj kada ih pokrenes , oni sami mogu da dobiju root privilegije , a samim tim i da izazivaju prekide , koji zatim dovode do prelaska u real mode , gde mozes da izvrsavas privilegovane instrukcije

zato je vrlo bitno da suid aplikacije nemaju sigurnosne propuste , sto se naravno desvalo u proslosti
sigurnosni propust u suid aplikaciji ti je otprilike isto sto i sigurnosni propust u kernelu ili driveru
jer njime dobijas root pristup , a samim tim i pristup kernelu a time i potpunu kontrolu nad sistemom

kao sto je Dimkovic istakao , na windowsu je to malo drugacije , iz protected moda mozes u real samo iz kernela odnosno drajvera


ali ni u kom slucaju ne mozes kao obican korisnik da izvrsvas privilegovane instrukcije

napravi mali asm program s samo jendom instrukcijom , recimo hlt , ili ti HALT instrukcija , koja obustavlja rad procesora

pokreni je kao obican korisnik pa ces videti sta ce se desiti

cak ga i u linuxu pokreni kao root , pa ces videti sta ce se desiti

pozdrav,
Aca

@Ivan Dimkovic
izgleda da svako voli svoje :)


inace oko sakrivanja procesa... ako neko ima root pristup, postoji ogromno nacina za sakrivanje procesa... cak moze i kernel da se patchuje... ili da se sakrije nesto u nekog od aktivni procesa. Posto postoje servisi koji prate izmene, ali i to se moze iskljuciti/popraviti/sakriti sa root nalogom :D

Sta je tu cudno Dimkovicu? Pa prvi rootkit-ovi su se pojavili na unixima, tacnije Solarisu (pardon SunOS-u) jos sredinom 90tih godina...

Izgleda da su za instaliranje ipak potrebne administratorske privilegije.