DirtyClone: nowa luka w jądrze Linuksa umożliwia lokalną eskalację uprawnień do roota - Security Bez Tabu

DirtyClone: nowa luka w jądrze Linuksa umożliwia lokalną eskalację uprawnień do roota

Cybersecurity news

Wprowadzenie do problemu / definicja

DirtyClone to nowo opisana podatność lokalnej eskalacji uprawnień w jądrze Linuksa, oznaczona jako CVE-2026-43503. Błąd dotyczy obsługi buforów sieciowych oraz mechanizmu przenoszenia fragmentów pamięci powiązanych z danymi plików. W praktyce umożliwia on lokalnemu użytkownikowi nadpisanie pamięci podręcznej stron dla pliku należącego do roota i uzyskanie uprawnień administracyjnych bez trwałej modyfikacji pliku na dysku.

W skrócie

DirtyClone należy do rodziny błędów określanych jako DirtyFrag i wynika z nieprawidłowego propagowania znacznika informującego o współdzieleniu fragmentów pamięci z pamięcią powiązaną z plikiem. Luka otrzymała ocenę CVSS 8.8 i może zostać wykorzystana lokalnie do uzyskania roota poprzez sklonowane pakiety sieciowe oraz ścieżki przetwarzania IPsec.

  • Podatność: CVE-2026-43503
  • Typ: lokalna eskalacja uprawnień
  • Wpływ: przejęcie uprawnień roota
  • Szczególnie zagrożone: hosty wieloużytkownikowe, kontenery, CI/CD i Kubernetes

Kontekst / historia

DirtyClone jest kolejnym wariantem szerszej klasy błędów związanych z interakcją między mechanizmami zero-copy networking a pamięcią powiązaną z plikami. W poprzednich przypadkach badacze wskazywali, że stos sieciowy błędnie traktował niektóre dane jako bezpieczne do modyfikacji, mimo że nadal wskazywały one na współdzielone strony pamięci.

To ważny przykład problemu, w którym kolejne poprawki usuwają konkretne ścieżki kodu, ale nie zawsze eliminują cały wzorzec podatności. W efekcie organizacje muszą brać pod uwagę nie tylko pojedynczą lukę, ale też całą klasę podobnych błędów w jądrze.

Analiza techniczna

Źródłem problemu jest nieprawidłowe przenoszenie znacznika SKBFL_SHARED_FRAG przez wybrane funkcje odpowiedzialne za operacje na fragmentach buforów sieciowych skb. Znacznik ten informuje jądro, że dany fragment pamięci odwołuje się do stron współdzielonych, w tym do page cache powiązanego z plikiem na dysku.

Jeżeli ten stan zostanie utracony podczas klonowania lub przesuwania fragmentów, dalsze operacje mogą błędnie uznać taki bufor za bezpieczny do modyfikacji in-place. Publiczne opisy problemu wskazują między innymi na funkcje __pskb_copy_fclone() oraz skb_shift(), które nie propagują tego stanu prawidłowo.

Scenariusz ataku polega na powiązaniu stron uprzywilejowanego pliku wykonywalnego z pakietem sieciowym, a następnie wymuszeniu klonowania tego pakietu. Kolejny etap wykorzystuje ścieżkę przetwarzania ESP/IPsec, gdzie dochodzi do modyfikacji danych. Ponieważ jądro utraciło informację o współdzieleniu fragmentów, zapis może trafić do pamięci podręcznej stron związanej z plikiem wykonywalnym.

Kluczowe jest to, że plik na dysku pozostaje niezmieniony. Modyfikacja zachodzi wyłącznie w pamięci jądra, co utrudnia wykrycie ataku przez tradycyjne mechanizmy kontroli integralności plików. Po restarcie systemu zmiana znika, jednak do tego czasu atakujący może już uzyskać trwały dostęp administracyjny lub wykonać działania poeksploatacyjne.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem DirtyClone jest lokalna eskalacja uprawnień do poziomu root. W środowiskach współdzielonych oznacza to możliwość pełnego przejęcia hosta przez użytkownika, który początkowo nie miał praw administracyjnych.

  • naruszenie poufności danych i poświadczeń,
  • ryzyko modyfikacji lub sabotażu obciążeń uruchomionych na hoście,
  • utrudniona analiza śledcza ze względu na brak zmian w plikach na dysku,
  • potencjalny wpływ na inne procesy korzystające ze współdzielonego page cache.

Szczególnie zagrożone pozostają serwery wielodostępowe, hosty kontenerów, runnery CI/CD, środowiska deweloperskie oraz klastry Kubernetes, w których nieuprzywilejowani użytkownicy mogą tworzyć przestrzenie nazw.

Rekomendacje

Podstawowym działaniem naprawczym jest aktualizacja jądra do wersji zawierającej poprawkę dla CVE-2026-43503. Organizacje powinny możliwie szybko sprawdzić status poprawek dostarczanych przez używaną dystrybucję i nadać priorytet systemom współdzielonym oraz hostom obsługującym kontenery.

  • ograniczyć lub wyłączyć nieuprzywilejowane user namespaces tam, gdzie nie są konieczne,
  • zminimalizować możliwość uzyskania CAP_NET_ADMIN przez procesy uruchamiane przez zwykłych użytkowników,
  • przeanalizować, które systemy rzeczywiście wymagają IPsec oraz powiązanych modułów jądra,
  • zaostrzyć polityki bezpieczeństwa dla kontenerów i środowisk wielodostępowych,
  • monitorować nietypowe uruchomienia binarek uprzywilejowanych oraz anomalie w przestrzeniach nazw,
  • uwzględnić błędy z rodziny DirtyFrag w modelowaniu zagrożeń.

Jeżeli szybkie wdrożenie poprawek nie jest możliwe, środkiem tymczasowym może być ograniczenie nieuprzywilejowanych przestrzeni nazw użytkownika oraz wyłączenie wybranych modułów związanych z ESP/IPsec, o ile nie są one krytyczne dla środowiska.

Podsumowanie

DirtyClone pokazuje, że pozornie niewielki błąd w obsłudze metadanych buforów sieciowych może doprowadzić do poważnej lokalnej eskalacji uprawnień w jądrze Linuksa. Dla zespołów bezpieczeństwa najważniejsze są szybki patch management, ograniczanie zbędnych uprawnień oraz przegląd ekspozycji środowisk kontenerowych i wieloużytkownikowych.

Źródła