Microsoft zatvara prisup kernelu za sve 64-bitne verzije Viste

Magovi ponovo udaraju:



Symantec upset with Microsoft's kernel-locking
Adobe, Symantec Criticize Vista to EU

Ja ne znam za vas, ali meni Microsoft Security Centar nije zaustavio ni jedog trojanca do sada, a ovi sto se sada bune - jesu. Kome verovati?
Ako ima pojedinaca da navedu svoje iskustvo koje ce me osporiti - nek navale.
Windowsovci, stavite ruku na srce i recite da od sad Symantec i Kaspersky mogu da otvore kiosk (ili cak lanac kioska) sa hot-dog-ovima, jer od sad svi verujemo da ce Microsoft paziti na nas racunar bolje od svih njih zajedno.
Konkurencija je ponekad dobra stvar, a u ovoj oblasti je preko potrebna. Svi smo bili svedoci trke velikih igraca na ovom segmentu trzista - ko ce izbaciti pre nove definicije za postojece pretnje..savrseno zdrava tendencija.
Opet, ne znam kako je vama sada, ali sama pomisao da ce ista firma koja je dozvolila sebi da pusti Internet Explorer 6.0 u opstu upotrebu , onakvom stanju, sada biti jedina zaduzena za bezbednost moje 64-bitne masine ..cini da se osecam nekako sigurnije..a vi (..kako 'te)?


_{[Ovu poruku je menjao Dusannn dana 12.10.2006. u 23:41 GMT+1]}

---

I posle kažu da je Veliki Brat priča za conspiracy-chase-re
Još jedan razlog za prelazak na Linux/BSD
Ne smeš koristiti monopol u jednom segmentu tržišta da bi stekao monopol u drugom. To je ono što Micrisift uporno pokušava. Od srca se nadam da će im se EU parlament nayebati majke, i zabraniti to njihovo s***** kome treba 1 GB RAMA da prikaže transparent prozore, i da ima fancy efekat kad kursorom pređeš preko dugmića za close i minimize, i zamisli, kad stisneš ono X za close na prozoru, prozor nestane sa fade-out efektom, a kada ga minimizuješ, on se izrotira i spusti. Fora za debile. Evo sad neće biti ni DX10 za XP, tako da prosto primoravaju ljude da kupe novi hardver i novi Winblows Stoke nezasite
Yebo ih njihov nbr.1 OS, meni moj Slackware sasvim odgovara ovakav kakav je.

P.S.
WINDOWS SUCKS !!!

Ti bash i ne znash mnogo o Visti i DX-u 10?

Samo ne valja ni logika: ne zatvarajte kernel, neka ljudi pišu viruse, da bismo mi imali posla. Ako ni virusi ni AV kompanije nemaju pristup kernelu meni se čini uredu. Ali ako pisci virusa uspiju da zaobiđu MS preventivu, a AV kompanije to ne mogu (legalno) onda nastaje problem.

---

Dusane trojanca nikada nikakav AV sw nece spreciti - to je program koji se jednom pokrene i u skladu sa privilegijama koje ima u tome trenutku, cini nejvecu stetu. Probaj ovaj trojanac ne unixu



Ako imas privilegije da brises i pises, ima i trojanac. As simple as that. Dalje, nemoj da si naivan da neko ne moze da ubaci takvu liniju u postinstall skriptu tvoga paketa, pazi da instaliras samo pakete sa sajtova kojima verujes.

Mladene, ako ti Slackware odgovara koristi ga. Stoji da ne odgovara vecini onih koji komp koriste, a MS mora ugoditi vecini da proda, makar neko tamo ko je u manjini poput tebe bio nezadovoljan.

Ajde da vidimo sta symantec kaze:


I sta da kazem nego OK. Sumnjam da ce moci da sprece propagaciju virusa (ukoliko se ne ugledaju na NetBSD - koji BTW u ovome casu koristim - ali propagaciju antivirusa hoce, sto je jos bolja stvar. Symantec? Imam iskustva sa njima, defragmenter koji obrise disk, lazno prijavljivanje virusa i neprijavljivanje virusa koje bi trebalo prepoznati...

Iskreno, vise sam podataka izgubio zbog Symanteca nego zbog virusa.

_{[Ovu poruku je menjao bojan_bozovic dana 13.10.2006. u 08:34 GMT+1]}

"Tehnologija" koja treba da "implementira" ovu genijalnu zamisao nazvana je PatchGuard.
Ona je zamisljena tako da bude middle-layer interfejs izmedju aplikacija koje se izvrsavaju i dela kernela koji upravlja procesima. Osecate li vetar u kosi?...to je zbog dodatne brzine koje donosi ovo resenje.
Jos nesto sto se propusta. Kontekste procesa koji su presli u "background" PatchGurard kriptuje rt i to 64-bitno (sto, jel' da - opet ubrzava sistem) i brise tu strukturu (plaintext procesa) do sledeceg ucitavanja. Kada se ponovo pojave, onda ih vraca tako sto ih dekriptuje, pa proveri i tek onda pusti u rezim izvrsavanja.
Dakle, tvoj odgovor/komentar "dokle god imas pravo da nesto pises i brises - imas trojanac" nije bas na mestu. Sta mislis, kako ce se jedan kvalitetan industry-strenght IDS/IPS nositi sa ovakvim "cudima moderne tehnologije" (PatchGuard)?
Mozda ce MS napraviti svoje super-sofisticirane programe za sigurnost, koji ce prevazici sve postojece! Jer svi znamo koliko MS brzo ulazi u nove oblasti...
Dodouse, uvek ostaje nova mogucnost da MS kupi firmu sa vec zaokruzenim proizvodom, ali, kada se gladni MS project menadzeri, podivljali od probijanja rokova pocnu penjati na glavu tim developerima, naviklim da rade u malim timovima...obicno su rezultati daleko ispod ocekivanog.

Evo zanimljive i kvalitetne analize PatchGuard-a.

Uh..zamisli dokle doseze moja naivnost..a ja do sada uporedjivao md5 checksum-ove!! Verovacu...verovacu...verovacu..

---

I netbsd veriexec i kriptosistem takodje ne moze da ubrza stvari, kao i slicno na drugim OS, zar ne? I dinamicko linkovanje je sporo, rebuilduj ceo sistem da je staticki linkovan.

Ako ti poturim rootkit ili trojanac u RPM mogu i checksum, zar ne? Pazljivo...

Dio kernela koji upravlja procesima? Scheduler i Dispatcher? (Ke*) ? Nema PatchGuard puno veze sa time. Osnovna je zamisao da se očuva integritet krucijalnih sistemskih (dakle kernel-mode, ring0, supervisor, zovi kako hoćeš) struktura, jer je njihova modifikacija od strane 3rd party drivera (obično rootkita, nerijetko i kretenski dizajniranih AV-ova) prvi korak ka BSOD-anju sustava.

Recimo već spomenuti KAV modificira SSDK (tablicu fjskih pointera na kernel-mode entrypointeve od sistemskih servisa), u svrhu filtriranja nepoćudnih i potencijalno malicioznih aktivnosti. Svatko tko je položio uvodni kolegij iz Operativnih Sustava zna da svi moderni general-purpose OS-evi imaju potpuno preemptive i reentrant kernel, da bilo kad kernel može preemptat bilo koji dio OS/driver koda u kernelu/userlandu, i nastavit ga izvršavat u neprediktabilno dalekoj budućnosti, ovisno o prioritetu, opterećenju sustava i scheduling polisi.

Modifikacija SSDT-a je nešto krajnje trivijalno za isprogramirati, i obično je koriste najlamerskiji rootkiti čiji se kodovi na netu mogu skinuti (rootkit.com i Hoglundova prepisana knjiga). Obično tada atomički (lock xchg) se zamjenjuje SSDT zapis API-ja koji se želi hookirati sa svojim hook handlerom, i atomički ga se opet zamjenjuje sa izvorno pohranjenim handlerom OS-a jednom kad se driver od rootkita/AV-a/IDS alata unloada.

Problem je što u trenutku kad vraćamo orignalni handler je moguće da n drugih threadova izvršava sa različitim EIP-ima kod našeg hook handlera što će, ako ga odhookamo u tom trenutku i nedajbože unloadamo driver, rezultirati bugcheckom sustava.

Kako za SSDT, tako i za ostale krucijalne strukture koje ne bi trebao modificirati nitko drugi osim OS-a samog - IDT, GDT, MSR_SYSENTER_EIP, a pogotovo ne in-place modifikacija OS koda samog (ntoskrnl, HAL i sl.).

Modifikacija dispatch tablice sistemskih servisa i sl. "hackovi" nisu nikad primjer dobre inženjerske prakse i primjer su lošeg dizajna. PatchGuard će u ovakvom obliku djelovati samo beneficirajuće na overall sigurnost kernela, jer, baš kao što skape kaže u tom tekstu:





1. Ne postoji "kontekst izvršavanja procesa", samo threadovi imaju kontekst izvršavanja (KTHREAD), proces je OS entitet koji objedinjuje kontekste svih threadova koji se pod njim izvršavaju i još gomilu drugih logičkih resursa. NT ima malko drugačiji proces model od tradicionalnih unixoida.

2. PATCHGUARD_CONTEXT struktura sadrži gomilu fjskih pointera i in-memory checksume od NTOSKRNL.EXE i HAL.DLL i još neke gluposti. Koliko je osjetno usporenje od XOR-iranja nekoliko stotina bajtova po 64 bita na x64 platformi ostaje pitanje za domaći rad.

3. Verifikacija tog patchguard contexta se ne odvija za vrijeme svakog context switcha (cca pola milijuna - milijun puta u sekundi na normalno opterećenom (tj. idle :) sustavu), kao što si ti dao perfidno naslutiti, već ti lijepo u skapeovom papiru piše da PatchGuard inicijalizira periodički timer koji queue-a DPC koji u slučajnom vremenskom intervalu (DPC-ove koriste driveri za kompletiranje I/O requesta, nedeterministički ih završavaju ovisno o prioritetu samog DPC-a nekoliko sistemskih kernel-mode threadova) sa određenom gornjom granicom (u tekstu nije specificirano koja je). Dakle vjerojatno svakih par sekundi se verificiraju te sistemske strukture i, ukoliko je došlo do promjene, sistem se forsirano BSOD-uje pozivanjem KeBugCheckEx().



Kvalitetan industry-strength IDS/IPS ne koristi prljave trikove "ispod haube", a PG je baš namijenjen za sprečavanje istih. Neće PG spriječiti ni rootkite i AV-ove da čine gluposti, jer kad se svi oni nalaze u istoj protekcijskog domeni kao i OS (ring0), pitanje zaštite postaje pitanje rat racea, ali da će PG natjerati ljude da pišu kvalitetniji kod - to je neporecivo.

---

Evo ga Sundance opet copy/paste iz udžbenika

Molio bih modove da se reaktiviraju po pitanju brisanja poruka (ili još bolje, banovanja sa foruma) trollova koji isključivo prakticiraju ad hominem argumentaciju, da se ne bi ponovila stara priča.

---

Nemoguce je zaista zastititi strukture procesom koji se izvrsava na istom sec. nivou na kom se svi ti grozni "malicious-system-crashing-hackalishous-poorly-written" (fuj fuj fuj) third-party softver izvrsava. To je poznato svakom ko je barem poceo da se bavi bezbednoscu. Naravno da to zna i Microsoft..evo linka ka blogu Scott Field-a , vodeceg arhitekte koji stoji iza ove ideje u Microsoft-u, sa sve potresnom zavrsnicom:

Ono sto ti perfidno pokusavas da plasiras je da kriterijum sta je dopustivo a sta nedopustivo ponasanje (multi/single threaded) procesa univezalna, vecita i nepromenljiva istina i da nju ne odredjuje Microsoft vec je samo usvaja kao takvu. WRONG!

Kada smo ogolili istinu, ispada da ce preosveceni MS gurui pokazivati zabludelim ovcama iz Adobe-a, Symantec-a i KasperskyLabs-a kako se u stvari bezbedno kodira za njihov kernel. Da li je neko rekao "exploatisanje monopola da bi se povecao uticaj na trziste", ne? Zatvorite oci, i zamislite svet gde ce microsoftovi programeri uciti ostale kako se koduje stabilan sistem.
Vidim veeeliki "no pasaran" u EU.
Btw, mislis da su gorepomenuti sw giganti toliko zeljni da "in vivo" modifikuju kriticne strukture u kernelu? Prakticno zive za to. WRONG. Soory, ali tom OS-u je to moralo biti uradjeno da bi se obezbedio minimum funkcionalnosti. W/ever gets the job done!
Nisam hteo (ma koliko me to vuklo) da iz informativne predjem u akademsku terminologiju, jer smatram da bi trebalo da tekst mogu da procitaju cak i oni nisu koji nisu imali prilike da (kao ti) prelistaju Silberschatz-a (Operating System Concepts) i slicne.
Pozdrav.

---

Naravno da zna, to sam i naglasio u prethodnoj replici na ovoj temi citirajući skapeovu konkluziju da ovakva proaktivna zaštita konzistentnosti krucijalnih kernel-mode struktura OS-a neće potpuno sprijećiti ni rootkite niti loše napisane AV-ove i drivere koji, umjesto da koriste formalna sučelja koja OS pruža u tu svrhu, preferiraju old-skul prčkanje po tablici sistemskih servisa, IDT-u, vezanoj listi struktura koje predstavljaju aktivne procese, MSR etc., već će povećati donju granicu složenosti (raise the bar) koja je potrebna za implementiranje takove filtering infrastrukture, te konsekventno tome natjerati developere da prije koriste formalni OS API nego nekakve dirty hackove (koji, mora se priznati, jesu elegantni, ali i loši sa stajališta dobrog dizajna).

Zašto imamo kernel, HAL, drivere, filesystem, protokol handlere....sve u istoj protekcijskoj domeni (prstenu)? Jebiga, ostatak još od davnih dana s početka 70-ih, poglavice mentaliteta u kojem je svaki CPU ciklus i svaki bajt memorije svet i skup k'o svetog Petra kajgana. Ironično je što x86 i danas ima 4 hardverske razine privilegija koje nijedan napredniji general-purpose OS ne iskorištava, sve iz razloga skupe tranzicije između njih. MULTICS ih je imao čak 8, a da su se Thompson&Ritchie malo više ugledali na uzor čiji su dizajn se okušali (loše) simplificirati, sigurnost današnjih OS-eva bi bila za tri koplja veća. Iako su i igri još neki malo prizemniji faktori (neki glupi RISC-evi, npr Alpha, podržavaju samo 2 PL..)

Ironično je doduše da MS u Visti masu driver infrastrukture pokušava offloadati u userland (UMDF), ulažeći herkulski napor da natjera gomilu 3rd party developera da prepišu iznova svoje drivere, i pritome dakako očuvajući API/ABI kompatibilnost sa što je moguće više starijim verzijama drivera. U 2006. godini bi gotovo svatko žrtvovao 5-10% CPU resursa za x puta sigurniji i stabilniji OS, nažalost prije 15 godina taj je postotak bio mnogo veći pa stoga trebamo pribjegavati ovakvom krpežu.



Ne znam odakle ti takva interpretacija onoga što sam iznio, ali ne vidim da sam se igdje pozivao na vječne i nepromjenjive Istine o kriterijima za podobnost izmjene kernelovih podatkovnih struktura, niti sam pokušao insinuirati postojanje istih.

NT je MS-ov OS i on je taj koji dirigira pravila igre, koji pruža ekosistem API-ja u obliku raznih frameworka i pravila dopustljivog i nedopustljivog (nedefiniranog) ponašanja, a koje 3rd party driver developeri imaju usvojiti ukoliko misle proći WHQL, odnosno očekivati da OS ne BSOD-uje zato jer je MS odlučio u sljedećem QFE-u promijeniti bazu od KeServiceDescriptorTable.

Oni produkti koji ne koriste dirty hackove neće nimalo beneficirati od ovog MS-ovog poteza, dok će dežurni generatori junk AV-ova (KAV, Symantec pogotovo, imate još na Asembler forumu jedan snippet od 15ak instrukcija koje NAV svojim genijalnim "heuristikama" detektira kao generički win32 infektor, ne trebam ni pričat da taj snippet koda ništa ne radi osim što se ruši pri izvođenju), koji revno slijede liniju manjeg otpora na radost mnogobrojnih pingvina i MS bashera pjevati žalopojke i prijetiti tužbama EU komisije (=gomile nesposobnih debelih seronja koji se nikad neće pomiriti sa činjenicom da USA praktično vodi sve konce IT industrije).



Hot-patching koji spominješ nema nikakve veze sa modificiranjem kernel-mode OS struktura. već sa runtime apliciranjem (uglavnom sigurnosnih) patcheva na način da se prije prologa funkcije (push ebp; mov ebp, esp) stavi dvobajtni junkcode (mov edi, edi) koji se izmjeni u short jump na kod od patcha. Na taj način se logika bilo koje kernel fje može on-the-fly izmjeniti bez potrebe za restartanjem OS-a.

Hot-patching postoji implementiran inače i na XP SP2, te WS2K3 SP1 x32, a svi oni nemaju PatchGuard. Dakle, ne radi se o nekakvom MS-ovom "backdooru", kao što ti pokušavaš dati do znanja zabludjelim i neukim masama, već o odavno poznatom featureu.

Jedina komponenta PG-a koja dozvoljava Hot-Patching jesu checksumi in-memory imagea od ntoskrnl i OS drivera, a sve ostale kernel-mode strukture (SSDT, IDT etc.) Hot-Patching mehanizam ne dira.



Tim AV-ovima bi bilo pametnije da updateaju svoje heurističke algoritme koje nisu značajnije principijelno unaprijedili desetljećima, umjesto da po blogovima proljevaju svoje mentalne prosere. No to bi opet značilo lišavanje milijonskog incomea od pretplatnog modela na definicije svježeg malware-a koji tako fino sjeda u duboke im džepove. Današnji rootkiti su u stanju sakriti se od skeniranja memorije uhakiranjem u Memory Manager OS-a (ShadowWalker tehnologija opisana u posljednjem phracku), loadati se prije početka OS-a u boot fazi i loadati kernel modificirajući ga za svoje subverzivne potrebe(BootRootKit genijalnog Dereka Soedera), pa čak i pokrenuti cijeli OS kao hypervisor utilizirajući virtualizacijske mehanizme modernih CPU-ova (Blue Pill još genijalnije Joanne Rutkowske, ženskog geeka koja usto nije ružna k'o noć :D).

Kako bi se zaboga ijedan IPS/AV mogao boriti protiv ovako nečeg? Trebao bi fundamentalno izmjeniti gomilu funkcionalnosti OS-a i raditi provjere na mnogim razinama, runtime enkriptirati masu koda da pruži 100%tnu odbranu od ovakvih napasti. Za većinu state-of-the-art rootkit tehnologija postoje specifični alati za detektiranje, koji i sami rade užasne hackove - npr. protiv DKOM-a koji izbacivanjem iz dvostruko vezane liste procesa (EPROCESS strukture) efektivno proces sakriva kako iz Task Manager, tako i svih drugih alata za enumeriranje aktivnih procesa. Postoji i Linux port DKOM-a (unlinka se iz liste task_struct-ova), da samo navedem kao primjer (oba schedulera su thread-based, ne process-based, pa se stoga i dalje izvršavaju threadovi unlikanih procesa). Praktično jedini način da sigurno detektiraš tako sakriven proces jest da patchuješ kernelov scheduler (SwapContext()) i usporediš listu procesa koji sadrže threadove koji su selektirani za izvršavanje, što je, moraš priznat, jaaaaako gadan i ružan hack, s obzirom da SwapContext() nije ni exportana niti javna (public) fja koja u svakom trenutku može promijeniti svoj signature (broj parametara, način povrata vrijednosti, lokaciju u memoriji).

Neka se granica mora povući, a PG i polisa da se ne dižu u kernel unsigned driveri su prvi korak ka eliminaciji kako rootkit gamadi tako i loše napisanih drivera, što će u konačnici djelovati pozitivno i za sigurnost i stabilnost OS-a.

Da se u krajnoj liniji više ne događa da skinem npr. IceSword i u dumpu SSDT-a vidim redirekciju u driver genijalno-h4k3rsk0g naziva d347bus.sys, i sve mi nešto desna pretklijetka počne poskakivat sve dok ne shvatim da je to driver od Daemon Toolsa :)

_{[Ovu poruku je menjao cynique dana 14.10.2006. u 17:36 GMT+1]}

---