Niezabijalne procesy


Service Manager jest jednym z moich ulubionych mechanizmów w systemie. Wiem, ze to moze dziwnie brzmiec, ale gdybym musial znalezc przyczyny, to chyba po prostu zdazylem sie do niego przyzwyczaic. Poza drobnymi modyfikacjami, Service Manager praktycznie nie zmienil sie odkad zaczalem sie interesowac wnetrznosciami systemu a kiedys, dawno temu (przed Windows 2000 i pojawieniem sie WMI) byl praktycznie jedyna metoda "namówienia" zdalnego komputera do uruchomienia jakiegos procesu. A to czasem bywalo cenne.

Temat nie dotyczy Service Managera samego w sobie, ale to wlasnie w jego kontekscie zauwazyc sie daje jedna ze zmian we wnetrznosciach systemu Windows. Jadro systemu, choc w oczywisty sposób ewoluuje, to w podstawowych zalozeniach pozostaje prawie niezmienione od czasów, gdy w 1988 roku (ponad 25 lat temu!) zaprojektowal je (nadal pracujacy w Microsoft!) Dave Cutler. Z czasem okazalo sie, ze jedna z idei, które powinny zostac przebudowane jest kwestia zaufania do kogos, kto ma prawa administratora. Z jednej strony, powinien móc wszystko, z drugiej jednak – w praktyce okazuje sie, ze moze jednak warto przed administratorem bronic krytycznych mechanizmów zapewniajacych integralnosc i bezpieczenstwo systemu. Niby mozna stwierdzic, ze skoro administrator oddal swoje uprawnienia jakiemus malware'owi to sam sobie jest winny, ale równoczesnie system operacyjny w samym srodku powinien pozostac odporny na popsucie.

Systemy Windows, w miare ewolucji stopniowo wprowadzaly rózne mechanizmy obronne poczynajac od efektownego Blue Screena 0xC000021A: STATUS_SYSTEM_PROCESS_TERMINATED po zabiciu csrss.exe, poprzez poziomy integralnosci az po flage w strukturze _EPROCESS (bardzo dokladne opisana na blogu Michala Grzegorzewskiego). Caly czas po to, zeby administrator nie mógl sam sobie za duzej krzywdy zrobic, choc czasem dodatkowo (flaga ProtectedProcess jest tu dobrym przykladem) w innych niecnych celach. Jednym z obszarów, które system próbuje bronic przed administratorem sa serwisy systemowe. Wystarczy spojrzec na serwis Group Policy Client (gpsvc). Uzytkownik nic z nim zrobic nie moze – to normalne. Ale administratorowi tez nie wolno go zatrzymac... Co jest o tyle dziwne, ze administrator, który faktycznie ma ochote to zrobic, moze go unieruchomic bez najmniejszego problemu. Ochrona na poziomie zarzadzania uslugami jest po prostu nieskuteczna. W koncu jednak zrobiono odwazny ruch i zamiast ukrywac przed administratorem kolejne interfejsy, którymi mozna system poprosic o zabicie krytycznego procesu, zabezpieczenie zaimplementowano w samym mechanizmie zabijania. Pora w takim razie na maly eksperyment: wystarczy Windows 8.1, Process Explorer i chwila zabawy z procesem NisSrv.exe. Zeby nie odbierac przyjemnosci odkrywania, nie podam konkretnego przepisu.

Mozna tez spojrzec na ochrone poprzez wbudowane w system narzedzie sc.exe – pojawil sie w nim nowy parametr qprotection i po wpisaniu sc.exe qprotection wdnissvc widac, ze system cos nam opowiada o ochronie serwisu/procesu.

ppl

Co z tego tak naprawde wynika? Po pierwsze, widac, ze system jest coraz lepiej uszczelniany, równiez po to, zeby bronil sie przed nierozwaznym/niedobrym administratorem. To ciekawe podejscie i na pewno bede czujnie przygladal sie zmianom w tym obszarze. A po drugie – wydaje mi sie, ze czeka mnie pare nieprzespanych nocy. Dokladne zrozumienie mechanizmu ochrony procesów i przyjrzenie sie jak on jest w systemie faktycznie uzywany na pewno chwile zajmie. Jezeli ktos zrobi to wczesniej ode mnie i zechce temat rzetelnie opisac, to tylko sie uciesze.

A czy faktycznie taka metoda ochrony procesów jest skuteczna? Hmm... jeszcze zobaczymy, ale nie wyglada to zle!

Autor: Grzegorz Tworek [MVP]

Comments (2)

  1. Anonymous says:

    Nie spotkałem się z tym i nie znam gotowego rozwiązania. Myślę, że warto byłoby zacząć od małego śledztwa dlaczego ten proces nie daje się zabić i potem na tej podstawie pomyśleć jak sobie w takiej sytuacji poradzić. Ale to czysto teoretyczne dywagacje…

  2. andrzej says:

    Pozostanę przy tytule wpisu.
    Gdy Skype zawiesi się, to procesu tego komunikatora nie da się zabić.
    Czy można taki proces zestrzelić w inny sposób, oprócz ponownego uruchomienia systemu?

Skip to main content