Vlákno názorů k článku Antivirus CD: Co dokáže a jak ho vyrobit? od Patrik - Preji pekny den. Protoze jsem v clanecku ne zcela...
-
Patrik (neregistrovaný)Preji pekny den.
Protoze jsem v clanecku ne zcela pochopil nektera vychozi tvrzeni autorky, rad bych pozadal o vysvetleni.
Jde mi o nasledujici informaci:
'„Windowsovské” antiviry nemají za běhu Windows přístup do jejich systémových souborů. Za běhu Windows se virus může před strážci systému schovat.'
Znamena to, ze antivirus do systemovych souboru nemuze a virus ano? Co znamena, ze se v systemovych souborech (bylo-li to tak mysleno) muze virus schovat? A jak se tam dostane, kdyz na rozdil od antiviru typicky nema autorizaci pro podobnou operaci?
Diky
P. -
Krysa (neregistrovaný)Ačkoliv jsem s windows nepracoval již dlouho, dovolil bych si připomenout ještě jednu skutečnost: Antiviry se ve windows na bázi NT(2000, XP) obvykle spouští pod uživatelem administrator. administrator ale není správce systému. Skutečnost je taková, že ve windows se ani správce nemůže přihlásit jako skutečný správce systému. Díky tomu nemůže ukončit procesy spuštěné pod skutečným správcem SYSTEM, ale obvykle může měnit systémové soubory. Změnou systémového soubory virem s právy administratora se může při příštím startu spustit proces, se kterým za běhu Windows podle mě dostupných informací nikdo nic nesvede.
-
K2 (neregistrovaný)Správcem systému je opravdu Administrator. Systémové procesy ovšem běží v kontextu System, nikoliv Administrator (na unixech je to jedno a totéž). Antiviry pracují také v kontextu System, a jsou rpavidla implementované jako drivery v řetězci mezi Win32 voláním pro práci si soubory a ovladačem disku (v tom řetězci je také file system, quota manager, šifrování a komprese na úrovni FS apod.). Z tohoto titulu může antivir přečíst cokoliv. Výjimkou je situace, kdy driver na nižší úrovni data ukryje, nebo když totéž provede kernelový modul (kernelový rootkit). To je ovšem problém na Windows stejně, jako na unixech, jen se kernelové rootkity u unixů asi tak často nevidí. Pro ilustraci si to lze zjednodušeně představit tak, že bych na Linuxu měl "zlý" (upravený) modul file systému ReiserFS, který by procesům ClamAV a Avast ukrýval některé soubory.
-
K2 (neregistrovaný)okamzite po navratu z probihajiciho syscallu, takže třeba neumřou vůbec... Ve Windows je to podobné, s tím, že lze ukončení procesu vynutit. Viz utilita kill ze support tools, nebo taskkill v XP+. Některé systémové procesy jsou obecně chráněné, aby je nemohl odstřelit každý, kdo má práva admina.
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Presne. Co sa tyka zaspavania v kerneli, jedna verzia k3b to vedela dokonale. Teraz pravdupovediac neviem, ci to bol bug priamo k3b, cdrecordu, driveru na CD mechaniku alebo kooperacny paradox - aj ked zase ziadny kernelovy kod by si toto dovolit ani pri chybnych argumentoch nemal ;-).
Proste proces bol natrvalo uspany v kerneli a nic moc s tym neslo spravit. -
Mard (neregistrovaný)Co to pises prosim tebe? Spravny virovy proces se ti ani nevypise v seznamu procesu :-) Tak co potom chces killovat? Nektere rootkity ti fakt system dost pozmeni. Me asi pred deseti lety, kdyz jsem s linuxem zacinal, nekdo napadl server a zavedl tam prima zmeny. Asi dva dny jsem to resil, nez jsem nasel vsechny backdoory. Prisel jsem na prunik zcela nahodou tak, ze se mi nezdaly velikosti systemovych souboru a udelal jsem binarni kontrolu se zalohou. Pak uz jsem ovsem zacal patrat podrobneji. Mohu te ale ujistit, ze ps mi se zadnym argumentem nic podezreleho nevypsalo.
-
Neni nutne nahrazovat ReiserFS. Je mozne se za behu systemu napojit mezi ReiserFS a VFS (tj. tesne nad ReiserFS) a ukryvat soubory na teto urovni. Krome toho je tu samozrejme moznost napojit se vys, na volani open (mezi aplikaci a puvodni open).
Jak jste ovsem spravne poznamenal, kernel-level rootkity jsou problemem u vsech systemu (krome tech co maji kernel v ROM). V Linuxu se vyskytuji mene predevsim proto, ze prumerny linux nestoji prumernemu crackerovi za nabourani (a to predevsim proto, ze linuxovy spravce linuxu obvykle rozumi vic nez windowsi administrator windows). -
Pro *nixy existovalo a existuje mnohem vic druhu rootkitu, protoze mnohe z nich jsou jen proof of concept a protoze kazdy *nix vyzaduje jiny rootkit (a napr. linux i jine pro 2.2, 2.4 a 2.6). Pod windows je rootkitu mene, ale IMHO jsou rozsirenejsi, je vic zarootkitovanych kompu, vice instanci rootkitu.
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Tak s tym mozem suhlasit, ja som pocital prave pocet druhov, nielen co sa tyka modifikacii pre jadra, ale celkovo rozlicne pristupy (plejada LKM rootkitov, vyhadzovanie sa z tabuliek procesov, ..., boot/init rootkity, pre ine *nixy ich uz tak dobre nepoznam, ale principy su podobne).
