P

odatności zatruwania stron pamięci podręcznej przeżywają aktualnie swoją chwilę sławy. 13 maja publicznie ujawniono kolejną lukę oraz exploit umożliwiający lokalne podniesienie uprawnień w systemie Linux o nazwie Fragnesia. Poprawka dla Dirty Frag wprowadziła sprawdzanie w obsłudze komponentu IPsec – ESP (ang. Encapsulating Security Payload), czy strony bufora są współdzielone ze stronami pamięci podręcznej (ang. page cache) przed wykonaniem odszyfrowania w miejscu (ang. in place). Przypomnijmy, że deszyfracja w miejscu to proces, w którym zaszyfrowane dane są odszyfrowywane i nadpisywane bezpośrednio na tych samych sektorach dysku fizycznego lub buforze pamięci, w których zostały pierwotnie zapisane. Zaletą tego procesu jest jego wydajność i brak wymogu dodatkowej przestrzeni dyskowej, ale wymaga za to ścisłej sekwencyjności operacji wejścia / wyjścia (I/O), aby uniknąć uszkodzenia nieodczytanych jeszcze zaszyfrowanych danych.

Niestety wprowadzona łatka w jądrze systemowym opierała się na prawidłowym ustawieniu flagi sprawdzającej (SKBFL_SHARED_FRAG), ale pięć innych ścieżek w kodzie pomijało ją bez żadnego sprawdzenia. Błąd o nazwie Fragnesia wykorzystuje właśnie te ścieżki. Jeśli flaga sprawdzająca zostanie usunięta, zanim spreparowany pakiet dotrze do komponentu ESP, weryfikacja kończy się sukcesem, a jądro deszyfruje dane w miejscu, nadpisując strony pamięci podręcznej. Wynik jest taki sam, jak w przypadku podatności Dirty Frag. Atakujący nadpisuje znajdujący się w pamięci podręcznej plik binarny, taki jak /usr/bin/su, a kolejny użytkownik, który go uruchomi, otrzymuje powłokę administratora. Warto zauważyć jeszcze jedną rzecz. Fragnesia została ujawniona bez jakiejkolwiek koordynacji z opiekunami jądra czy dystrybucjami Linuksa. Publiczny kod na dowód słuszności koncepcji (ang. Proof-of-Concept – PoC) został wydany w tym samym momencie, w którym poprawka została przesłana do głównego strumienia poprawek dla jądra Linux. Brak wcześniejszego powiadomienia, brak okresu embargo, brak czasu dla dostawców na przygotowanie poprawek przed upublicznieniem sploita. Taka jest dzisiaj rzeczywistość, w której przyszło nam pracować. Dlatego szybkość reakcji zespołów bezpieczeństwa ma tak ogromne znaczenie.

Tymczasowa metoda mitigacji pozostaje taka sama jak w przypadku Drity Frag: zablokowanie możliwości ładowania modułów jądra esp4 oraz esp6. Dlatego jeśli nasza konfiguracja systemów posiada jeszcze aktywne zabezpieczenia przed Dirty Frag to system jest też chroniony przez Fragnesią. Jednak na tym historia się nie kończy. Dyskusja na liście LKML (ang. Linux Kernel Mailing List) pokazuje, że główni programiści jądra zaczeli przyglądać się innym ścieżką, które wpisują się w ten schemat działania. Po ujawnieniu Fragnesii Sultan Alsawaf jeden z inżynierów CIQ, użył narzędzia Claude Code do systematycznego audytu stosu sieciowego w jądrze Linuksa. Kod został przeszukany pod kątem dodatkowych ścieżek, w których mogłaby występować ta sama klasa błędu (brak propagacji wcześniej wspomnianej flagi SKBFL_SHARED_FRAG). Poprawka w drugiej wersji autorstwa Hyunwoo Kima (który napisał oryginalną poprawkę dla Dirty Frag i podjął działania w celu rozwiązania problemu Fragnesii) naprawiła trzy miejsca w pliku skbuff.c, ale Sultan chciał wiedzieć, czy istnieją inne, które nie zostały znalezione. I były.

Sultan odkrył, że funkcja: skb_gro_receive() w podsystemie GRO (ang. Generic Receive Offload) jądra zawierała dokładnie ten sam błąd związany z propagacją bezpiecznej flagi. Gdy GRO scala fragmenty bufora gniazda, przenosi deskryptory fragmentów bez propagacji flagi współdzielonego fragmentu (ang. shared-fragment flag). Po scaleniu, szybka ścieżka ESP traktuje fragmenty stron pamięci podręcznej jako zapisywalne — i otrzymujemy dokładnie ten sam mechanizm uszkodzenia stron pamięci podręcznej (ang. page-cache corruption primitive), co w przypadku oryginalnego eksploita Fragnesia, tyle że przez zupełnie inny punkt wejścia. Sultan nie poprzestał na znalezieniu błędu. Stworzył pełny exploit demonstrujący PoC, który standardowo celował w program super user (/usr/bin/su) poprzez ścieżkę GRO. Potwierdził on jego działanie i opublikował zarówno exploit, jak i poprawkę na liście dyskusyjnej jądra Linuksa. W ciągu kilku godzin Hyunwoo Kim włączył poprawkę GRO Sultana do trzeciej wersji głównej łatki jądra. Przy okazji Hyunwoo dostrzegł inną problematyczną ścieżkę GRO, której poprawka Sultana nie obejmowała, i również ją naprawił. Wynikowa łatka dla jądra obejmuje wszystkie pięć podatnych miejsc w dwóch plikach źródłowych.

Innym ciekawym przypadkiem jest to, że dwa niezależne zespoły znalazły na podstawie Dirty Frag pokrewną lukę związaną z protokołem RxRPC, którą nazwali DirtyDefrag / DirtyCBC. Zespół V12 – od Fragnesii, 9 maja znalazł kolejny wektor wejścia do protokołu RxRPC, ale raportując ją otrzymali informację o duplikacie. Teraz swoim, analogicznym odkryciem pochwalił się Delphos Labs. O ile DrityFrag wykorzystywał ścieżkę RxKAD (starszego mechanizmu zabezpieczeń opartym na protokole Kerberos 4) w protokole RxRPC, gdzie przestarzała konstrukcja FCRYPT czyniła go podatnym na atak typu brute force. O tyle DirtyCBC bierze również na cel protokół RxRPC, ale tym razem mechanizm RxGK (oparty na GSS-API), który wykorzystuje szyfrowanie AES-256-CTS-HMAC-SHA1. Jednak atak brute force nie miał tu zastosowania. Na początku warto wyjaśnić, że w bezpiecznej komunikacji szyfrowanie uwierzytelnione (ang. AE – Authenticated Encryption) lub szyfrowanie uwierzytelnione z powiązanymi danymi (ang. AEAD – Authenticated Encryption with Associated Data) stanowi złoty standard zapewniający zarówno poufność, jak i integralność danych. Fundamentalną zasadą bezpiecznej implementacji tych systemów jest to, że szyfrogram musi zostać w pełni uwierzytelniony zanim zostanie odszyfrowany lub – co najwyżej – zanim jakiekolwiek odszyfrowane dane zostaną ujawnione aplikacji bądź wpłyną na stan systemu. Złamanie tej zasady wprowadza klasyczny błąd kryptograficzny: deszyfrowanie przed weryfikacją MAC (ang. Message Authentication Code). Odkryta podatność wynikała właśnie z faktu, że jądro Linuksa deszyfrowało przychodzące pakiety RxRPC bezpośrednio do stron pamięci podręcznej przed zweryfikowaniem ich kryptograficznej sumy kontrolnej (MAC). Atakujący mógł wysłać złośliwy pakiet z ładunkiem i nieprawidłowym kodem MAC. Jądro systemu chętnie odszyfrowywało ten ładunek wprost do stron pamięci podręcznej. Mimo, że weryfikacja MAC w kolejnym kroku kończyła się niepowodzeniem, a system traktował pakiet jako nieprawidłowy to strony pamięci podręcznej pozostawały „brudne” (ang. dirty), przechowując odszyfrowane bloki danych wstrzyknięte przez napastnika. Jeśli użytkownik lub proces odczytał plik, zanim dana strona brudnej pamięci została usunięta (ang. evicted) lub nadpisana przez prawidłowy pakiet to użytkownik odczytywał dane zmodyfikowane przez atakującego. Błąd ten łamał gwarancję integralności, jakie miało zapewniać szyfrowanie uwierzytelnione.

Dzisiaj, na przykładzie nowego wektora lokalnego podniesienia uprawnień, widać, że społeczność tworząca oprogramowanie musi zacząć działać proaktywnie. Fale szybkiego odkrywania pierwotnych lub spokrewnionych podatności przez i z pomocą agentów AI już tu są. Cztery przypadki LPE (ang. local privilege escalation) powiązane z zatruwaniem stron pamięci podręcznej w zaledwie trzy tygodnie: Copy Fail, Dirty Frag, Dirty Decrypt / CBC i Franesia. Wzorzec jest jasny. Społeczność musi nie tylko skupić się na szybkim wdrażaniu poprawek do głównych strumieni obsługiwanego oprogramowania, ale również znajdowaniu błędów pokrewnych przed ich kolejnym ujawnieniem.

Więcej informacji: DirtyCBC: When Linux Kernel Decrypt-Before-MAC Turns Authenticated Encryption Into a Page-Cache Write, Fragnesia, We predicted the next wave. Five days later, we found it ourselves