W dobie wszechobecnych exploitów warto zastanowić się nad zabezpieczeniami. Solar Designer, założyciel inicjatywy OpenWall niedawno poinformował o pojawieniu się nowego projektu do proaktywnej ochrony systemów opartych na Linuxie.
LKRG, bo o nim mowa, to opracowany przez naszego rodaka, Adama „pi3” Zabrockiego, moduł jądra składający się z trzech różnych podsystemów proaktywnej ochrony. Kluczową kwestią jest to, że rozwiązanie zostało zaprojektowane z myślą o wykrywaniu wystąpienia pewnych scenariuszy ataków, a nie konkretnych, znanych podatności. Dzięki temu istnieje możliwość, że okaże się „ostatnim bastionem” w momencie, kiedy złośliwe oprogramowanie spróbuje skorzystać z technik exploitacji, które nie są jeszcze znane.
Jak wygląda ochrona zapewniana przez LKRG?
Podsystem integralności oferowany przez LKRG ochroni przed nieautoryzowanym nadpisywaniem pamięci jądra systemu. Jego działanie polega na okresowym wyliczaniu sum kontrolnych z newralgicznych miejsc jądra za pomocą algorymu SipHash, który został zaprojektowany do zastosowania w wydajnym uwierzytelnianiu informacji. Wspomniana procedura jest również uruchamiana po wykryciu aktywności modułów jądra lub po wystąpieniu określonych zdarzeń w systemie (np. zmiana interfejsu sieciowego). Analogiczną funkcję na Windowsie pełni PatchGuard.
Drugim aspektem ochrony jest podsystem wykrywania exploitów, który monitoruje, czy w systemie nie występują nietypowe sytuacje, takie jak np. nadpisanie process credentials i uzyskanie zwiększonych uprawnień przez proces bez żadnej wiarygodnej przyczyny. Podejrzane procesy tego typu są natychmiast zabijane, zanim uda im się doprowadzić atak do końca.
Eksperymentalna wersja modułu oferuje również trzecią funkcję pod nazwą „Protected Features”. Dzięki niej możliwe jest np. zablokowanie zapisu do logów systemowych w trybie innym niż append-only, nawet jeżeli operacja została zainicjowana przez administratora. Skutecznie uniemożliwia to „zacieranie śladów” przez potencjalnego atakującego. Zdjęcie blokady wymaga wydania polecenia kernelowi i uwierzytelnienia się specjalnym hasłem, które administrator powinien przechowywać poza systemem.
Podobne funkcje silnej ochrony mają zastosowanie również w stosunku do zwykłych plików i procesów. Istnieje np. możliwość zabezpieczenia procesu ssh-agent przed debugowaniem, wykonaniem zrzutu pamięci i innymi tego typu interakcjami, które mogą prowadzić do „wyciągnięcia” kluczy prywatnych z pamięci procesu. Podobnie jak w przypadku logów, na zabezpieczony proces nie będzie mógł wpłynąć nawet root.
Czy rzeczywiście ktoś może zaatakować mój kernel?
Każde oprogramowanie zawiera błędy. Przez to, że Linux jest mniej popularny wśród użytkowników końcowych, odkryte podatności niekiedy odbijają się znacznie mniejszym echem, niż w analogicznych sytuacjach związanych z Windowsem. Przykładami prawdziwych exploitów na jądro Linux są choćby CVE-2014-9322, CVE-2017-5123, CVE-2017-6074, czy CVE-2017-1000112. Wszystkie z wymienionych potencjalnie mogą prowadzić do przejęcia uprawnień administracyjnych na zaatakowanym systemie.
Wykorzystanie błędu w implementacji obsługi protokołu DCCP do eskalacji uprawnień użytkownika na administratora.
Obecność modułu LKRG rzeczywiście uniemożliwia wykorzystanie wymienionych wyżej podatności na niezałatanych systemach, pomimo że nie był projektowany pod kątem wykrywania tych konkretnych exploitów. Niestety, jak to zwykle bywa, bezpieczeństwo kosztuje. Okresowe sprawdzanie integralności jądra oraz działanie podsystemu detekcji exploitów, według oficjalnych benchmarków autora, wiąże się ze spadkiem wydajności sięgającym około 6.5%.
Uważny czytelnik zauważy, że takie rozwiązanie nie chroni również przed popularnym atakiem Meltdown, który odbywa się na innej warstwie abstrakcji. Ataki wycelowane w podatności znajdujące się poza jądrem (w tym przypadku wręcz w samym procesorze) nie zostaną wykryte. Analogicznie z atakami, które są całkowicie pasywne i nie zostawiają zbyt wielu śladów, ale pozwalają np. na zrzucenie pamięci jądra. Autor deklaruje jednak możliwość pojawienia się specjalizowanej detekcji takich ataków w następnych wersjach modułu. Ponadto, gdyby w przyszłości pojawił się nieznany exploit umożliwiający nadpisywanie pamięci jądra (nawet na poziomie sprzętu!), obecność LKRG faktycznie mogłaby przeszkodzić w jego wykorzystaniu.
Innym powiązanym aspektem jest to, że LKRG nie rozróżnia exploitów od „modyfikacji jądra w dobrej wierze”, co uniemożliwi uruchomienie rozwiązań polegających na łataniu jądra w sposób inny niż oficjalnie rekomendowane. Przykładem może być choćby KSplice, choć nadal da się go użyć, jeżeli LKRG zostanie załadowany dopiero po dokonaniu patchowania).
Podsumowanie
Autor omawianego modułu podchodzi do sprawy realistycznie i wyraźnie podkreśla to, że omawiany tutaj moduł nie jest „lekiem na wszystko”, tym bardziej że możliwość ominięcia zabezpieczeń wynika z samego sposobu jego działania. Moduł zaskakująco dobrze radzi sobie jednak z wykrywaniem ataków zero-day. W dobie wszechobecnych zagrożeń warto jednak rozważyć jego instalację, szczególnie na serwerach, jeżeli w danym zastosowaniu wyższy priorytet nad maksymalną wydajnością ma dla nas zwiększone bezpieczeństwo. Jeśli projekt Was interesuje, zajrzyjcie na jego stronę lub do dedykowanej Wiki, gdzie znajdziecie bardziej obszerne informacje i odpowiedzi na ewentualnie nurtujące Was pytania. Z autorem można porozmawiać na naszym kanale IRC (#z3s@IRCNET).
Komentarze
No tylko, ze poza Ubuntu to ciezko to nawet skompilowac, a nie caly swiat sie kreci wokol Ubuntu.
Ciężko nawet odpowiedzieć na ten komentarz. ;) „Nie umiem, do dvpy!”.
Wiele projektów miewa błędy lub nie zawsze działa,
więc po coś, tam, jakiś, system zgłaszania lub zapytania istnieje ?
Prawda ?
Argument jak najbardziej zasadny, to dopiero wstępna wersja projektu rozwijanego głównie przez jedną osobę w czasie wolnym. Jeżeli wzrośnie zainteresowanie, zapewne też wzrośnie wsparcie.
Michał, jak ktoś chciałby testować zamiast narzekać, to by sobie odpalił choćby VM z Ubuntu. Jednak narzekać jest przecież dużo łatwiej, prawda? :)
Mylisz narzekanie z wytknieciem wady wieku niemowlecego. Potestowalem sobie na Ubuntu, ale nie jest tajemnica, ze patch srednio dziala z innymi kernelami niz te od Ubuntu a, ze swiat nie kreci sie wokol Ubuntu to tyle w temacie. Mam nadzieje, ze jako doswiadczony ladmin teraz po rozrysowaniu zrozumiesz.
To nie jest patch kernela, to ładowalny moduł. To daje pewne rokowania na przyszłość w kwestii rozszerzania wsparcia.
LKRG bez problemu kompiluje sie na jadrach 'vanilla’ (3.x oraz 4.x), zostal rowniez testowany (z sukcesem) na dystrybucjach RedHat’owskich wlaczajc w to: Fedora, CentOS, VzLinux (Virtuozzo 7), oraz Debian’owskich, wlaczajac w to: Debian 8 (z malymi modyfikacjami, o ktorych mozna przeczytac na liscie mailingowej LKRG), Debian 9, Ubuntu 15*, Ubuntu 16*, Ubuntu 17*. Nie jest to prawda, ze tylko Ubuntu jest wspierane. Jesli wystepuja jakies problemy, chetnie sie im przyjrze ;) Wiecej informacji na temat listy mailingowej, oraz kontaktu jest dostepnych na oficjalnej stronie projektu => http://openwall.com/lkrg/
Pozdrawiam ;)
@WujekPawel: zwrócenie uwagi wieku dziecięcego? Nie rozśmieszaj nas. Tekst o tym, że „nie wszystko kręci się wokół Ubuntu” bije na kilometr nastawieniem w stylu „dla mojej uber-pro-hipsterskiej dystrybucji nie ma tutoriala krok po kroku, a banda lamerów na swoim przedszkolnym ubuntu ma już to odpalone – to niedopuszczalne”. :)))
Ktoś kombinował z Arch’em?
Czy ktoś łopatologicznie wytłumaczy mi jak to zainstalować w Ubuntu 17.10 – jestem początkujący w Linuxie. Przeczytałem tutka z oficjalnej strony ale nic nie kumam a bardzo chcę tego dodatkowo uzyć. Dziękuję.
Najpierw wywołaj komendy:
$ cd /tmp$ sudo apt-get install linux-headers-$(uname -r) build-essential git
$ git clone https://bitbucket.org/Adam_pi3/lkrg-main.git
$ cd lkrg-main
$ make -j8
które zainstalują wszystkie potrzebne narzędzia, pobiorą kod źródłowy do katalogu tymczasowego i skompilują go.
Później zrób:
$ modinfo output/p_lkrg.kopowinny wyskoczyć podstawowe informacje na temat modułu (nazwa, autor itp.)
Finalnie zainstaluj moduł:
$ sudo insmod output/p_lkrg.ko p_init_log_level=3i wywołaj:
$ sudo tail /var/log/kern.log | grep lkrgpowinna pojawić się informacja:
[p_lkrg] LKRG initialized successfully!moduł się instaluje ale po restarcie nie ma po nim śladu, powinienem przekopiować go do katalogu /lib/modules? Szczerze mówiąć próbowałem lecz nie wykrywa go.
Odpowiedziałem sobie sam, zostawiam dla potomnych:
Zamiast
$ sudo insmod output/p_lkrg.ko p_init_log_level=3Kopiujemy moduł do nowo utworzonego katalogu
$ sudo cp output/p_lkrg.ko /lib/modules/wersja_kernala/kernel/lkrgNastępnie wykonujemy
$ sudo depmod -aTworzymy plik z opcjami uruchomienia w katalogu
$ sudo mcedit /etc/modprobe.d/p_lkrgo treści:
options p_lkrg p_init_log level=3Następnie wykonujemy
$ sudo modprobe p_lkrgi powinno działać również po restarcie ;)
Autorze drogi, nie patrz na komentarze bo tu znowu gimnazjum o dystrybucje wojuje zanim sie na tresci skupic.
A teraz będzie, mam nadzieję że konstruktywna, krytyka ;-) Tak, przeczytałem artykuł, dokumentację, kod nawet i znam threat model.
Sit back, relax and enjoy the ride.
Moduł do kernela jest lepszym pomysłem niż patch. Linus nic związanego z security, zwłaszcza jeśli skomplikowane, nie wpuści ;)
Moduł znacznie zwiększa attack surface.
Działa na tym samym poziomie uprawnień, co obiekt który chroni.
Dowolny kernel exploit albo ma albo może banalnie zbudować „arbitrary read-write primitive”. Co posłuży do wyłączenia LKRG.
Niektóre exploity na jądro iOS tak działały, ścigając się z KPP. Jasna, lista zdarzeń, kiedy jądro jest weryfikowane jest spora, ale to statystyka i kiedyś można ten wyścig wygrać. To samo z Windows.
Żeby zwiększyć swoje szanse, obciążę system, sama weryfikacja też chwilę musi zająć.
Ochrona jądra z Windows 10 i iOS jest aktualnie lepsza, bo działa na innym poziomie uprawnień i wyłączenie wymagałoby uruchomienia kodu w TZ (iOS) lub tej-dziwnej-VM-obok-Windowsa (Windows ;).
Zawsze mogę zdążyć zapisać coś do jądra, LKRG mnie zabije, ale będzie za późno.
Mogę też zapisać, zrobić swoje i przywrócić poprzedni stan.
Widzę, ża autor zadbał o CAP_SYS_RAWIO. A jak z innymi capabilities, które też można ciekawie wykorzystać?
Czy autor zabezpieczył jądro przez zapisem przez proces, który sobie podniesie uprawnienia przez iopl()? Jasne że ono wymaga CAP_SYS_RAWIO ale jeśli mój proces już je ma, mogę pisać wszędzie. Trzeba całkiem zabronić.
To samo z /dev/kmem – trzeba by go całkiem zabronić.
Mogę zapatchować jądro an dysku i poczekać aż się serwer zrebotuje, lub go wywrócić.
Inne bajery, jak zabezpieczone logi, zabezpieczenie przed debugowaniem, zrzuceniem pamięci są albo już obecne (RSBAC, SELinux, Grsecurity) lub można je obejść przez wykonanie kodu w jądrze.
> Zawsze mogę zdążyć zapisać coś do jądra, LKRG mnie zabije, ale będzie za późno.
Jeżeli wcześniej będzie potrzebny krok pośredni z podniesieniem sobie w jakiś sposób uprawnień to proces zostanie ubity zaraz po tym fakcie.
Samego LKRG oczywiście da się ominąć na różne sposoby. Zabezpiecza on jednak przed sytuacjami, do których w ogóle nigdy nie powinno dojść. IMHO po prostu jest spora szansa, że jakiś mało ogarnięty rootkit zostanie dzięki temu zatrzymany. Jeżeli mówimy o atakach celowanych to właściwie czego by nie zrobić to i tak atakowany ma przerąbane.
> A teraz będzie, mam nadzieję że konstruktywna, krytyka ;-) Tak, przeczytałem artykuł, dokumentację, kod nawet i znam threat model.
>
> Sit back, relax and enjoy the ride.
>
Licze na to ;-)
> Moduł do kernela jest lepszym pomysłem niż patch. Linus nic związanego z security, zwłaszcza jeśli skomplikowane, nie wpuści ;)
>
Glowny powod, dla ktorego LKRG jest modulem, jest wyjasniony na stronie: „Being a kernel module (not a kernel patch), LKRG can be built for and loaded on top of a wide range of mainline and distros’ kernels, without needing to patch those.”. Daje to mozliwosc tzw. „massive deployment” i jesli ktos chcialby zintegrowac LKRG na calej farmie serwerow, to mozna ten problem sprowadzic do masowej instalacji kolejnego pakietu – powniewaz instalacje modulow moga niczym sie nie roznic od instalacji zwyklego pakietu w systemie. Dodatkowo, diametralnie zmniejsza sie „trudnosc” uzywania z punktu widzenia uzytkownika – nie ma przymusu recznej rekompilacji kernela (na co wiele osob nie ma czasu, a niekiedy wiedzy). Za kazdym razem, gdy kernel sie zmienia / aktualizuje, operacja musialaby byc powtorzona. W przypadku modulow wystarczy przygotowac nowa paczke i znow wykonac „massive deployment / update” (po aktualizacji kernela).
Ponadto, tak jak zostalo wspominane w cytacie, kolejnym (moze i glownym) benefitem jest to, ze pomimo ingerencji w „core” systemu, znacznie prosciej jest wspierac rozne indywidualne „backporty” latek aplikowanych przez rozne dystrybucje Linux’a. A bywaja one naprawde szalone – jest to jedna z przyczyn dlaczego grsec nie jest kompatybilny z wieloma kernelami roznych dystrybucji (bazuje na vanilla).
Kolejna przyczyna jest istnienie w niektorych organizacjach takich serwerow, ktore z wielu roznych przyczyn sa bardzo rzadko restartowane. LKRG mozna zaladowac na systemie ktory nie byl restartowany latami i bedzie dzialal jak nalezy. Jesli cos jest patch’em na kernel, to automatycznie takie maszyny nie beda z tego korzystac.
> Moduł znacznie zwiększa attack surface.
>
Nie zgadzam sie z tym stwierdzeniem (ale chetnie poznalbym argument przeciwko). „Attack surface” jest dokladnie taki sam teraz, jak w przypadku gdyby LKRG byl „patch’em” na kernela. Przeciez dodatkowy interfejs, ktory uzytkownik moze atakowac z „user-space”, jest taki sam gdyby zostal udostepniony jako core-kernel czy poprzez modul.
> Działa na tym samym poziomie uprawnień, co obiekt który chroni.
>
Jesli ktos w jakis sposob uzyskal dostep do ring-0 (w sposob niezauwazalny dla LKRG – o czym Michał Leszczyński wspomnial w swoim komentarzu i dobrze wyjasnil, gdzie lezy istota problemu), to wowczas zaczyna sie zabawa w kotka i myszke, z ktorej wygraniem LKRG bedzie mial problem z definicji. Natomiast, nawet wtedy jest ogromna roznica miedzy kernel’em posiadajacym i nieposiadajacym LKRG. Otoz teraz atakujacy ma zasadniczo 2 podejscia. 1) Dzialac tak, by LKRG go nie zauwazyl i dalej uzyskac to co sie zamierzalo. 2) Zaatakowac LKRG, kompletnie go wylaczyc i powrocic do normalnego trybu infekcji. Kazdy inny sposob zostanie przez LKRG zauwazony (w przyszlosci ubity). Problem z 1) jest taki ze LKRG de facto „zmusza” atakujacego do grania na takich zasadach, na jakich LKRG mu pozwoli. Im wiecej ograniczen, tym mniejsza swobode posiada atakujacy. Z kazda iteracja LKRG, mniej i mniej „funkcjonalnosci” bedzie mozna modyfikowac, by zostac niezauwazonym. Dodatkowo, zmusza to do wiekszej komplikacji kodu atakujacego, zwieksza jego koszty oraz czesto moze wplywac na zmniejszenie „reliability”, co sie bardzo negatywnie odbija na atakujacym. W przypadku scenariusza 2) z kazda iteracja LKRG coraz trudniej bedzie mozna go obejsc (przynajmniej takie jest zalozenie). Znow wchodzimy na te sama droge, kod zaczyna byc skomplikowany, pominiecie chociaz 1 kontekstu dzialania LKRG bedzie skutkowac wykryciem atakujacego (poniewaz dziala on na roznych event’ach w systemie, zwieksza to trudnosc wylapania wszystkicih kontekstow w jak najkrotszym czasie, by nie zostac „zlapanym”), zmniejsza „reliability”. Ten sam problem mial Windowsowy PatchGuard, gdy tylko powstal. Po paru iteracjach od powstania nikt nie stara sie go obchodzic (poza ludzmi z research by udowodnic, ze jest to bardzo ciezkie, ale wykonalne), tylko przewazajaca wiekszosc atakujacych stara sie dzialac w oberbie punktu 1) – wlaczajac w to bardzo zaawansowane rootkit’y (stuxnet? flame?). Efektem koncowym jest to, ze nie mamy juz calkowitej samowolki, a w wiekszosci po prostu wszystko jest zrzucane do user-mode (bo tak jest prosciej) ;)
> Dowolny kernel exploit albo ma albo może banalnie zbudować „arbitrary read-write primitive”. Co posłuży do wyłączenia LKRG.
>
Tez sie z tym nie zgadzam, jest bardzo wiele rodzajow bug’ow ktore z trudem mozna w poczatkowej fazie przerobic na R/W-primitive – dla przykladu wszystkie bledy klasy 'swapgs’, czyli BadIRET, SysRet, etc. Nawet zakladajac, ze mamy juz R/W-primitive, zwieksza sie prawdopodobienstwo ubicia kernel’a zanim obejdzie sie LKRG – redukcja „reliability” exploitow jest bardzo pozadana ;) Dodatkowo, na chwile obecna nie skupialem sie na self-defense (inne wazniejsze rzeczy w projekcie byly bardziej priorytetowe), ale na pewno na ktoryms etapie zwroce wieksza uwage, by utrudnic atakowanie LKRG samego w sobie. Na chwile obecna, zeby zwiekszysc uprawnienia procesu i byc nizauwazonym dla LKRG, nalezy wygrac pare wyscigow (np. jesli najpierw zmodyfikuje sie drzewa czerwono-czarne na ktorych sa trzymane oryginalne metadane procesow, ale LKRG uruchomi procedure sprawdzajaca bo losowy event go wywola, a atakujacy jeszcze nie zaatakowal oryginalnego procesu, wowczas tez to zostanie wykryte. Nalezy byc na tyle szybkim, by znalezc to drzewo w pamieci, miec na tyle szczescia ze drzewo nie jest w trakcie tzw „self-balance” – drzewo sie czesto samo mutuje, zmodyfikowac wpisy w drzewie, nastepnie zaatakowac oryginalny process, no i zrobic to na tyle szybko by w miedzyczasie LKRG nie zostal wywolany z procedurami sprawdzajacymi). Owszem jest to wykonalne, ale zmniejsza sie stabilnosc exploita. W przyszlosci na pewno kod samoobronny zwiekszy koszty jeszcze bardziej (powniewaz na chwile obecna mozna powiedziec, ze nie ma kodu samoobronnego ;p).
> Niektóre exploity na jądro iOS tak działały, ścigając się z KPP. Jasna, lista zdarzeń, kiedy jądro jest weryfikowane jest spora, ale to statystyka i kiedyś można ten wyścig wygrać. To samo z Windows.
>
> Żeby zwiększyć swoje szanse, obciążę system, sama weryfikacja też chwilę musi zająć.
>
LKRG moze zarezerwowac jeden core tylko dla siebie na czas sprawdzania i wylaczyc wszelkie IRQ, by byc priorytetowym zadaniem i zeby nikt go nie wywlaszczyl w czasie wykonywania.
> Ochrona jądra z Windows 10 i iOS jest aktualnie lepsza, bo działa na innym poziomie uprawnień i wyłączenie wymagałoby uruchomienia kodu w TZ (iOS) lub tej-dziwnej-VM-obok-Windowsa (Windows ;).
>
ARM’y maja swoje TrustZony, ktore zamkniete platformy wykorzystuja i jednolica, by moc implementowac swoje ochrony w tej warstwie (np. KNOX Samsunga czy KPP iOS’a). Windows ma VSM, niezaleznie od architektury (przynajmniej najnowsze Windowsy wspieraja VSM na ARM rowniez). Roznica jest taka, ze Linux jest pare lat wstecz z takimi rozwiazaniami i bardzo dlugo sie zastanawialem czy z definicji nie zaprzac ring -1 do LKRG. Po dlugich analizach jednak doszedlem do wniosku, ze na chwile obecna rozwoju Linux’ow jest to bardzo niepraktyczne i postaram sie wyjasnic dlaczego. Otoz „standardowo” kazdy !nowy! Windows dziala z wlaczonym hypervisorem Hyper-V. Poprzez takie podejscie zostalo wymuszone, by Hyper-V obslugiwal „nested virtualization” i ma to robic dobrze – inaczej uzytkownicy nie mogliby uzywac innych hypervisorow i byliby troche wkurzeni. Pomimo tego, dalej nie kazda wersja „zewnetrznych” hypervisorow jest kompatybilna z Hyper-V. Jakie hypervisory w Linux sa standardem? Nie ma czegos takiego jak „standardowy hypervisor” w Linux. Czesc uzywa KVM, czesc Xen,a czesc VirtualBoxa, etc. Kazdy z nich jest inny, czesc z nich ma mozliwosc wspierania „nested” czesc nie ma, te co maja nie wlaczaja tego w standardzie (jak Hyper-V). Ogolnie na tym polu jest „wolna amerykanka” i bardzo ciezko byloby bazowac na hypervisorze, jesli nie wiadomo jaki jest i czy w ogole jest. Windows poszedl nawet dalej i zrobil VSM’a bazujac wlasnie na tym, ze wszedzie dziala Hyper-V. VSM jest „ustandaryzowany” i mozna budowac swoje rozwiazania bazujac na tym co VSM wspiera i udostepnia. Cos takiego nie istnieje na Linux’ach. Malo tego, nawet gdyby istnialo, ile „hosting’ow” sprzedajacych VPS’y gdzie mozna postawic Linux’a, wspieraja „nested virtualization” i pozwalaja dla guest Linux’a zainstalowac swojego hypervisor’a? Poza Microsoftowym Azure nie znam zadnego. Jesli podstawa LKRG bylby hypervisor, wowczas drastycznie zmniejszylaby sie potencjalna baza uzytkownikow, bo malo gdzie by to dzialalo ze wzgledu na brak wymaganej konfiguracji. Jestem pewien, ze to predzej czy pozniej sie zmieni, ale na chwile obecna jest to „dziki zachod”. Dla przykladu Amazon przez ogromna wiekszosc czasu uzywal Xen’a w swojej strukturze, a od roku przerzucil sie na KVM. Kompletnie rozny hypervisor, wiec rozwiazania ktore sie integrowaly z Xen juz nie beda dzialac na nowej infrastrukturze Amazona. Kiedy juz Linux’y pod tym katem sie ustabilizuja, wowczas nie ma zadnego problemu z dopisaniem (zreszta mam to w planach) czegos a’la HyperGuard, ktory chroni LKRG’a – tak jak jest to w Windowsach.
> Zawsze mogę zdążyć zapisać coś do jądra, LKRG mnie zabije, ale będzie za późno.
>
Na chwile obecna LKRG zmiany w jadrze tylko raportuje do logow, natomiast jesli projekt bedzie na tyle dojrzaly, ze bede czul sie 100% komfortowo, ze wedlug mojej wiedzy zaden FP nie istnieje, wowczas bedzie opcja wymuszenia 'crash’ systemu, gdy integralnosc systemu zostanie naruszona. Wowczas Twoj szybki zapis bedzie skutkowal wywaleniem systemu.
> Mogę też zapisać, zrobić swoje i przywrócić poprzedni stan.
>
Tak, ale nie bedziesz mial wtedy „persistent” modyfikacji w ring0, a o to chodzi wiekszosci rootkit’om – wciaz jednak jest mozliwosc robienia data-only rootkits. Jest to mozliwe, ale znow stabilnosc i funkcjonalnosc takich rootkit’ow jest mocno ograniczona.
> Widzę, ża autor zadbał o CAP_SYS_RAWIO. A jak z innymi capabilities, które też można ciekawie wykorzystać?
>
Funkcjonalnosc CAP_SYS_RAWIO zostala zmodyfikowana w „experimental” LKRG i ma troche inne znaczenie niz oryginalnie (teraz kontroluje RAW disk access oraz RAW mem access, gdzie standardowo nie ma takiego CAP_*, ktory by kontrolowal oba). O jakich innych CAP_* ktore moga byc grozne z punktu widzenia LKRG mowisz?
> Czy autor zabezpieczył jądro przez zapisem przez proces, który sobie podniesie uprawnienia przez iopl()? Jasne że ono wymaga CAP_SYS_RAWIO ale jeśli mój proces już je ma, mogę pisać wszędzie. Trzeba całkiem zabronić.
>
Jesli nie jestes „Protected Process”, to nie jest mozliwe wykonanie tego, o czym piszesz (tak jak sam zauwazyles nie majac CAP_SYS_RAWIO iopl() / ioperm() nie zadziala). „experimental” branch pozwala tylko dla „Protected process” posiadac takie przywileje.
> To samo z /dev/kmem – trzeba by go całkiem zabronić.
>
Tylko „Protected Process” ma do tego dostep – bajer w „experimental” branch.
> Mogę zapatchować jądro an dysku i poczekać aż się serwer zrebotuje, lub go wywrócić.
>
Od tego jest Secure-boot i pochodne zabezpieczenia – opisalem to w Threat-model, ze jest to out-of-scope.
> Inne bajery, jak zabezpieczone logi, zabezpieczenie przed debugowaniem, zrzuceniem pamięci są albo już obecne (RSBAC, SELinux, Grsecurity) lub można je obejść przez wykonanie kodu w jądrze.
Grsec / SELinux w ogole nie adresuja tych problemow, ktorych LKRG – wszystkie te projekty maja calkowicie inny target i inny threat model. Zreszta, duzo rozmawialem ze spender’em (tworca grsec), dlaczego grsec nigdy nie bedzie adresowal tych problemow, z ktorymi mierzy sie LKRG ;p
Pozdrawiam :)
Zaciekawiło mnie zdanie: „Moduł zaskakująco dobrze radzi sobie jednak z wykrywaniem ataków zero-day”. Jakie konkretnie zerodeje moduł wykrył i z czym to było porównywane ?
Przykład: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-1000112.html
Wyszło relatywnie niedawno, wersje LKRG wydane wcześniej niż ten exploit wykrywają go bez problemu.