Od renderera Chrome’a do kernela Linuksa: kompleksowy exploit Google Project Zero

W 2021 roku programista z Oracle postanowił dodać do kernela Linuksa nową funkcję komunikacji między procesami. Chodziło o możliwość wysyłania pilnych sygnałów przez lokalne gniazda sieciowe – coś, co wcześniej działało tylko w połączeniach TCP. Funkcjonalność trafiła do kernela i wylądowała w Linuksie 5.15. Cóż, jak się okazuje, ta niszowa funkcja używana niemal wyłącznie przez produkty Oracle stała się nieoczekiwaną powierzchnią ataku dla eksploitów sandbox escape – i to w najbardziej popularnej przeglądarce świata.

TLDR:

• Funkcja pilnych wiadomości dodana przez Oracle do kernela Linuksa zawiera lukę, którą można wykorzystać do ucieczki z sandboxa Chrome’a bezpośrednio do pełnej kontroli nad systemem
• Użytkownicy Linuksa 6.9 i nowszych powinni natychmiast zaktualizować kernel do wersji 6.9.8+ lub wyłączyć problematyczną funkcję.

Jann Horn z Google Project Zero opublikował szczegółowy opis exploitu, który pozwala na eskalację uprawnień bezpośrednio z sandboxa renderera przeglądarki Chrome do uzyskania pełnej kontroli nad kernelem Linuksa. Co gorsze, podstawowa luka bezpieczeństwa (CVE-2025-38236) jest trywialna do wywołania – wystarczy kilka podstawowych wywołań systemowych związanych z komunikacją między procesami. Problem tkwi w obsłudze pilnych wiadomości przez mechanizm lokalnej komunikacji w nowszych wersjach Linuksa.

Warto przypomnieć, że funkcja pilnych wiadomości (MSG_OOB) jest używana niemal wyłącznie przez produkty Oracle. To kolejny przykład ezoterycznej funkcjonalności kernela, która zostaje przypadkowo udostępniona przez sandbox przeglądarki. Twórcom Chrome’a udało się zablokować używanie tej funkcji w rendererze w odpowiedzi na lukę, ale sam fakt, że ta niszowa opcja była dostępna, ilustruje szerszy problem z powierzchnią ataku współczesnych sandboxów.

Wykorzystany tu błąd powstaje w funkcji zarządzającej buforami komunikacji pozostawionymi po odebraniu pilnych wiadomości. W określonej sekwencji wywołań – konkretnie po dwóch parach wysłania i odebrania pilnych wiadomości, kolejnym wysłaniu takiej wiadomości i odebraniu bez flagi pilności – dochodzi do use-after-free. Kernel zwalnia bufer, ale pozostawia wiszący wskaźnik, który może być następnie użyty przy kolejnym odbiorze z flagą pilności.

Horn nie zadowolił się zwykłym proof-of-concept, ale zbudował kompletny, funkcjonalny exploit. Używając prymitywu odczytu (możliwość czytania z arbitralnych adresów kernela) oraz prymitywu zapisu (inkrementacja określonej wartości w zwalnionym obiekcie), zdołał przejść całą drogę od sandboxa do kontroli nad kernelem. Kluczową innowacją było wykorzystanie mechanizmu bezpieczeństwa kernela, który losowo przesuwa wskaźnik stosu przy każdym wywołaniu systemowym.

Horn zrealizował, że zamiast szukać odpowiedniego obiektu na stercie do nadpisania, może realokować zwalnianą stronę pamięci jako część stosu kernela. Dzięki losowości przesunięć stosu, wystarczy wielokrotnie wywoływać funkcje systemowe i sprawdzać ich położenie na stosie, aż randomizacja ustawi stos we właściwej pozycji. To sprytne obejście mechanizmu, który teoretycznie miał chronić przed tego typu atakami.

Finalny exploit jest fascynująco złożony: wykorzystuje alokacje tabel stron do manipulacji alokatorami pamięci, odczytuje struktury kernela poprzez arbitrary memory access, spowalnia operacje kopiowania danych przez manipulację dużymi obszarami pamięci, a kończy nadpisaniem tabeli stron przez wyjście poza granice przy zapisie do pipe’a. Na koniec tworzy mapping własnej tabeli stron do przestrzeni użytkownika, zyskując możliwość mapowania dowolnej pamięci kernela.

Horn wykorzystał w exploicie zaskakująco dużą liczbę interfejsów kernela dostępnych w sandboxie Chrome’a: od oczywistych jak alokacje pamięci czy lokalne gniazda sieciowe, przez pomocnicze jak funkcje synchronizacji i monitorowania stanu, aż po niespodziewane jak funkcje pobierania numeru CPU. To pokazuje, jak szeroką powierzchnię ataku oferuje nawet ograniczony sandbox.

Co jeszcze wynika z tej historii? Automatyczne narzędzie do testowania kernela (syzkaller) wykryło tę lukę dopiero po dwóch miesiącach od jej wprowadzenia, mimo że sama sekwencja wywołań nie była skomplikowana – wymagała tylko sześciu podstawowych operacji. Problem w tym, że musiały być one wykonane w określonej kolejności. Horn trafnie zauważa, że fuzzing ma problem z odkrywaniem błędów wymagających precyzyjnych sekwencji – prawdopodobieństwo trafienia na właściwą kombinację wykładniczo maleje z każdą dodatkową operacją. To może być obszar do usprawnień w narzędziach testujących, które powinny lepiej eksplorować interakcje w ramach pojedynczych podsystemów kernela.

Exploit Horn’a stanowi mistrzowski przykład łańcucha technik wykorzystywanych w nowoczesnych exploitach kernela. Od realokacji stron pamięci jako buforów komunikacji, przez wykorzystanie mechanizmów ochrony jako narzędzi ataku, aż po wykorzystanie funkcji bezpieczeństwa jako pomocy w eksploitacji. W Chrome już zablokowano funkcję pilnych wiadomości w sandboxie, ale szerszy problem nadal pozostaje: ezoteryczne funkcje kernela wystawiane przez podstawowe interfejsy stanowią nieoczekiwaną powierzchnię ataku.

Nam pozostaje się zastanawiać, ile jeszcze podobnych „ukrytych funkcji” czeka na odkrycie w sandboxach nowoczesnych przeglądarek. Horn zapowiada bardziej systematyczną analizę sandboxa Chrome’a na Linuksie – i można się spodziewać, że nie będzie to ostatnie słowo w tej sprawie. Pełny opis exploitu wraz z działającym kodem znajduje się w bugtrackerze Google Project Zero.

Kto jest zagrożony?

W pierwszej kolejności użytkownicy Linuksa w wersji do 6.9.7 – starsze kernele nie zawierają podatnego kodu, chyba że ktoś backportował tę funkcjonalność. Szczególnie narażeni są użytkownicy Chrome’a na linuksowych desktopach, gdzie exploit może zostać uruchomiony bezpośrednio z przeglądarki. Horn testował swój kod na Debian Trixie z architekturą x86-64, ale podatność dotyczy prawdopodobnie wszystkich dystrybucji z nowszymi kernelami. 

Co z tym zrobić?

Jeśli perspektywa uzyskania kontroli nad kernelem przez napastnika nie przykuła jeszcze wystarczająco waszej uwagi, oto na czym trzeba się skupić:

• Łatanie systemu to priorytet numer jeden. Poprawka jest już dostępna od kernela w wersji 6.9.8, gdzie błąd w zarządzaniu pamięcią został naprawiony. To najlepsza obrona. Jeśli nie można natychmiast wdrożyć najnowszego kernela, warto rozważyć tymczasowe środki zaradcze.
• Wyłączenie problematycznej funkcji może być rozwiązaniem dla administratorów kompilujących własne kernele. Wystarczy ustawić CONFIG_AF_UNIX_OOB=n podczas konfiguracji. Ta funkcja i tak nigdy nie była szczególnie przydatna poza światkiem Oracle’a, więc jej wyłączenie nie zaszkodzi większości środowisk.
• Filtrowanie wywołań systemowych za pomocą seccomp to opcja dla zaawansowanych użytkowników. Można ograniczyć to, jakie operacje mogą wykonywać nieufne procesy – w tym przypadku filtrować wywołania send() i recv() z flagą pilnych wiadomości (OOB). To jednak wymaga precyzyjnej konfiguracji, żeby nie zepsuć normalnego działania systemu.

źródło: Project Zero

~Adam Golański