Odnalezione zostały trzy błędy w głównym jądrze Linux’a, które mają około 15 lat! Jeden z nich umożliwia lokalną eskalacja uprawnień (LPE) w wielu środowiskach Linuxa.
Badacze z GRIMM na swoim blogu ujawnili błędy występujące w jądrze Linux od 2006 r., czyli od momentu, rozwoju wsparcia dla iSCSI.
Co to jest SCSI?
SCSI (Small Computer System Interface), czyli słynne „skazi” – to standard przesyłania danych (magistrala danych) do łączenia urządzeń peryferyjnych w komputerze, pierwotnie za pośrednictwem fizycznego kabla, używanego między innymi do podpięcia twardych dysków. System SCSI został opublikowany w 1986 roku i do niedawna był powszechnie wykorzystywany głównie w wysokiej klasy serwerach i stacjach roboczych. Szczególna jego wersja to iSCSI, czyli SCSI przez TCP.
Odkryte błędy jądra systemu Linux
Według badacza bezpieczeństwa z GRIMM, Adama Nicholsa, „wady wpływają na wszystkie dystrybucje Linuksa, ale na szczęście podatny moduł jądra scsi_transport_iscsi nie jest domyślnie ładowany do systemu”.
Nowoodkryte luki to:
- Przepełnienie bufora sterty w podsystemie iSCSI (CVE-2021-27365) Wersje, których dotyczy problem: RHEL 8.1, 8.2 i 8.3 Wpływ: LPE, wyciek informacji, odmowa usługi (DoS)
- Wyciek wskaźnika jądra, który można wykorzystać do określenia adresu struktury iscsi_transport. (CVE-2021-27363) Wersje, których dotyczy problem: RHEL 8.1, 8.2 i 8.3 Wpływ: wyciek informacji
- Możliwość dostępu do jądra w trybie odczytu poza zakresem (CVE-2021-27364) Wersje, których dotyczy problem: przetestowano na RHEL 8.1, 8.2 i 8.3 Wpływ: wyciek informacji, DoS
Exploit
Specjaliści z Grimm wykonali testy na różnych wersjach Linux. Użyli do nich specjalnie napisanego exploit’a PoC. W wyniku uruchomienia exploita odpala się skrypt w zakodowanej na stałe lokalizacji (/tmp/a.sh) na uprawnieniach root. Repozytorium zawiera skrypt demonstracyjny, który tworzy plik należący do root’a w /tmp. Exploit nie jest w 100% niezawodny, więc może wymagać wielu uruchomień. Możliwe błędy obejmują ostrzeżenia, takie jak „Failed to detect kernel slide” i „Failed to overwrite iscsi_transport struct (read 0x0)” oraz błędów typu „kernel panic”. Dane wyjściowe z udanego przebiegu przedstawiono poniżej:
Wpływ na bezpieczeństwo
Ze względu na niedeterministyczny charakter przepełnienia sterty pierwsza luka może zostać wykorzystana jako niekontrolowany lokalny atak DoS (Denial Of Service). Jednak w połączeniu z wyciekiem informacji luka ta może być dalej wykorzystywana jako LPE, która umożliwia osobie atakującej przejście z konta użytkownika nieuprzywilejowanego do konta roota.
Druga luka (wyciek wskaźnika jądra) ma mniejszy wpływ i może służyć jedynie jako potencjalny wyciek informacji. Podobnie jest z trzecią luką, która ogranicza się do funkcjonowania jako potencjalny wyciek informacji lub nawet jako niekontrolowany lokalny atak DoS.
„W systemach CentOS 8, RHEL 8 i Fedora nieuprzywilejowani użytkownicy mogą automatycznie ładować wymagane moduły, jeśli zainstalowany jest pakiet rdma-core” – napisał na blogu Nichols z Grimm.
„W systemach Debian i Ubuntu pakiet rdma-core automatycznie załaduje dwa wymagane moduły jądra tylko wtedy, gdy sprzęt RDMA jest dostępny. W związku z tym luka ma znacznie bardziej ograniczony zakres”.
Jak sobie radzić z problemem?
Wszystkie trzy luki zostały załatane w wersjach:c5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260 i 4.4.260, a łaty są dostępne w głównym jądrze Linux dopiero od 7 marca 2021.
Jeśli masz już zainstalowaną jedną z powyższych wersji jądra Linuxa, Twoje urządzenie/serwer nie jest narażone na ataki wykorzystujące opisane błędy.
Złą informacją jest to, że poprawki nie zostaną wydane dla nieobsługiwanych wersji jądra EOL (End Of Life), takich jak 3.x i 2.6.23.
Jeśli nie załatałeś swojego systemu, możesz skorzystać z poniższego diagramu opublikowanego przez GRIMM, w celu sprawdzenia, czy Twoje urządzenie jest narażone na próby wykorzystania tych luk przez cyberprzestępców.
Podsumowanie
Opisywany problem należy na pewno do ciekawych. Wymienione w nim podatności mogą pozwolić atakującym przejąć pełną kontrole nad serwerami Linux bądź urządzeniami do których uzyskają dostęp lub doprowadzić do ataku DoS. Jak twierdzi Grimm na swoim blogu: „Opisywany wektor ryzyka jest znany od lat i istnieje kilka zabezpieczeń przed automatycznym ładowaniem modułów, w tym MODHARDEN grsecurity i ostateczna implementacja głównego mainstrem’a: „modules_autoload_mode”, zmienna „sysctl modules_disabled”, czarne listy dystrybucji poszczególnych rodzin protokołów i stosowanie czarnych list modułów specyficznych dla maszyny.” Są to dodatkowe opcje, których można użyć w strategii zaawansowanej obrony, w której administratorzy serwerów i programiści mogą podejmować zarówno środki reaktywne, jak i proaktywne.