Dirty Frag – kolejna metoda na root’a pod Linuxem

Pamiętacie Dirty Pipe? Łataliście ostatnio  Copy Fail? Pasy zapięte? Nie? To niedobrze, bo kilka godzin temu pojawiła się nowa podatność określona mianem Dirty Frag. W ramce poniżej znajduje się tymczasowe rozwiązanie mające na celu wyłączenie niebezpiecznych modułów. Jest to luka klasy LPE (local privilege escalation), która pozwala na podniesienie uprawnień lokalnego użytkownika do root’a. Tak samo jak w przypadku poprzedników, podatność nie wymaga wygrania wyścigu (ang. race condition), a to powoduje, że skuteczność exploitacji jest całkiem wysoka. Konstrukcja tego typu ataków sprawia, że prawdopodobieństwo wystąpienia kernel panic (lub żartobliwie – popłochu jądra) w przypadku niepowodzenia jest bardzo niskie. Dla atakujących – bardzo dobrze; dla obrońców – jest problem, bo patche nie trafiły jeszcze do wszystkich podatnych dystrybucji. 

TLDR:

• Krytyczne LPE (Local Privilege Escalation): Dirty Frag to luka pozwalająca na uzyskanie uprawnień roota w większości współczesnych dystrybucji Linuksa.
• Zatrucie Page Cache: Exploit omija mechanizm Copy-on-Write (COW), łącząc funkcję splice() (zero-copy) z kryptografią in-place (moduły ESP lub RxRPC), co pozwala na nadpisanie plików systemowych (np. /usr/bin/su) bezpośrednio w pamięci RAM.
• Z powodu przedwczesnego wycieku exploita, oficjalne łatki dopiero trafiają do repozytoriów. Doraźnym rozwiązaniem jest natychmiastowe zablokowanie modułów jądra: esp4, esp6 oraz rxrpc

W opublikowanym na portalu GitHub opisie, zamieszczono informację, że istnienie podatności wykazano w większości nowoczesnych dystrybucji. Przedstawiony PoC został z sukcesem przetestowany między innymi na poniższych dystrybucjach:

• Ubuntu 24.04.4: 6.17.0-23-generic
• RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
• openSUSE Tumbleweed: 7.0.2-1-default
• CentOS Stream 10: 6.12.0-224.el10.x86_64
• AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
• Fedora 44: 6.19.14-300.fc44.x86_64

Złą wiadomością (mamy pewne teorie na ten temat) jest fakt, że responsible disclosure nie żyje i nic nie wskazuje na to, że sytuacja miałaby się poprawić. Pięciodniowe embargo informacyjne dotyczące tej podatności zostało złamane niemal natychmiast po zmergowaniu patcha do netdev, dlatego zgodnie z zasadami ustalonymi z osobami odpowiedzialnymi za bezpieczeństwo kernela, znalazca opublikował pełen writeup. 

WAŻNE – zastosowanie mitygacji popsuje obsługę IPSec w kernelu Ponieważ potrzebne łatki nie trafiły jeszcze do dystrybucji istnieje tymczasowy workaround, który należy traktować jako rozwiązanie doraźne. Po opublikowaniu odpowiednich łatek, należy zastosować je bezzwłocznie.  Workaround polega na wyłączeniu modułów jądra, w których występuje ta konkretna podatność: sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Z grubsza podatność wynika z tego, że atakujący może zmusić kernel do modyfikacji plików, do których powinien mieć tylko dostęp read-only. Exploit nadużywa mechanizmu optymalizacyjnego zero-copy, który pozwala uniknąć kopiowania dużych struktur danych przekazując jedynie referencję do strony pamięci. Użytkownik otwiera plik, do którego ma dostęp tylko do odczytu (np. /usr/bin/su – ta sama binarka, która została wykorzystana przez exploit Copy Fail). Następnie wykorzystuje mechanizmy sieciowe Linuxa oraz funkcję splice() i interfejs sieciowy (lokalna pętla zwrotna), aby wstawić bezpośrednią referencję do załadowanej już w pamięci podręcznej (page cache) strony tego pliku prosto do struktury pakietu sieciowego – omijając de facto mechanizm Copy on Write. Przez mechanizm wykonania operacji kryptograficznych, podczas przetwarzania pakietu, możliwa jest modyfikacja in place bufora frag struktury sk_buff (wykorzystując ESP lub RxRPC). A ponieważ referencja wskazuje na kopię w cache, tzn. ten bufor jest współdzielonym wskaźnikiem na page cache, to kernel modyfikuje niechcący kopię “zabezpieczonej” binarki w pamięci podręcznej. Wykonując tę operację wiele razy, atakujący de facto sukcesywnie podmienia binaria znajdujące się w pamięci podręcznej. W momencie wykonania wskazanej binarki przez system lub użytkownika, kernel wykonuje kod podstawiony przez atakującego. 

Jak doszło do złamania embarga? Standardowo, w momencie kiedy poprawka trafia do publicznego upstreamu, badacze bezpieczeństwa (a także złośliwi aktorzy) dokonują porównania różnic w kodzie i na podstawie poprawki wnioskują jaki jest wektor ataku i ew. przygotowania exploita na lukę n-day (czyli taką, o której dostawca oprogramowania wie, ale jeszcze nie wdrożył albo jest na etapie wdrażania łatek). Użytkownik _SiCk twierdzi, że publikacja jego repozytorium, nazwanego Copy Fail2: Electric Boogaloo, nie było celowym i złośliwym działaniem, mającym wyprzedzić publikację patcha, a on sam nie wiedział o istnieniu umowy dotyczącej opóźnienia publikacji informacji o explocie. 

Pierwszy patch, gotowy do zainstalowania pojawił się w repozytorium testowym dystrybucji AlmaLinux.

Dlaczego obserwujemy wysyp podatności typu LPE, akurat teraz? Odpowiedź jest prosta. Badacze zapoznali się z mechanizmami, które doprowadziły do powstania podatności takich jak Copy Fail i starają się przełożyć podobny sposób myślenia na inne elementy kernela. Oznacza to, że poszukują podobnych wzorców w kodzie, aby wykorzystując podobne elementy (tzw. primitives), osiągnąć zbliżony efekt. Według nas możemy zobaczyć kilka podobnych podatności w najbliższej przyszłości. Należy pamiętać, że LLMy, mimo swoich wad, bardzo dobrze radzą sobie właśnie w analizowaniu powtarzających się wzorców, więc badania ukierunkowane na wykrycie podobnych mechanizmów przyspieszą. 

Co robić? Należy sprawdzić, czy nasze dystrybucje są podatne. Jeśli tak jest, to jedyną metodą jest obserwowanie repozytoriów dostawców w oczekiwaniu na łatki. Doraźnie należy zastosować mitygację polegającą na wyłączeniu podatnych modułów. 

Black Hat Logan