Dirty Clone – kolejny sposób na roota pod Linuksem

Nie tak dawno pisaliśmy o serii podatności Dirty Frag występujących w większości nowoczesnych dystrybucji Linuksa. I choć mogłoby się wydawać, że deweloperzy naprawili błędy, to najnowsze badania pokazują, że problem nie został jednak wyeliminowany. W jądrze pozostała bowiem niezałatana luka, którą badacze z JFrog ochrzcili mianem Dirty Clone (CVE-2026-43503). Podobnie jak jej poprzedniczki, nowa podatność należy do klasy LPE (local privilege escalation).

TLDR:

• Badacze z JFrog wykryli kolejną podatność klasy LPE (Local Privilege Escalation) z rodziny Dirty Frag – Dirty Clone (CVE-2026-43503).
• Luka pozwala na uzyskanie uprawnień roota w większości współczesnych dystrybucji Linuksa.
• Poprzez manipulację funkcjami klonującymi pakiety, cyberprzestępca jest w stanie zmodyfikować zawartość pamięci podręcznej stron (page cache) dla plików systemowych z flagą SUID. 
• W efekcie zyskuje możliwość wykonania dowolnego kodu z najwyższymi uprawnieniami.
• Oficjalne poprawki bezpieczeństwa wydane z końcem maja 2026 r. naprawiają wykryty błąd.

Okazało się, że poprawki bezpieczeństwa (naprawiające Dirty Frag) załatały jedynie jedną z alternatywnych ścieżek przetwarzania pakietów sieciowych w podsystemie XFRM/IPSec. Z powodu nieprawidłowego zarządzania referencjami do współdzielonych stron pamięci (w strukturach sk_buff), jądro systemu może zostać zmanipulowane do nadpisanie danych w pamięci podręcznej (page cache), które teoretycznie powinny być dostępne wyłącznie w trybie do odczytu (read only). W efekcie prowadzi to do manipulacji krytycznych plików systemowych i pozwala na podniesienie uprawnień lokalnego użytkownika do roota.

Aby dokładnie zrozumieć na czym polegał błąd, należy wyjaśnić pokrótce czego dotyczą optymalizacje sieciowe w Linuksie. Kiedy jądro tworzy pakiet sieciowy (opisany za pomocą struktury sk_buff), jego dane mogą pochodzić bezpośrednio z systemowej pamięci podręcznej stron (page cache). Jeżeli strony pamięci są powiązane na przykład z bibliotekami systemowymi lub innymi plikami na dysku (/usr/bin/su), wtedy jądro oznacza taki pakiet specjalną flagą bezpieczeństwa – SKBFL_SHARED_FRAG. Dzięki niej podsystem sieciowy wie, że dane w pakiecie są współdzielone z plikami i nie mogą być bezpośrednio modyfikowane. Ewentualne zmiany są możliwe dopiero po utworzeniu kopii (mechanizm Copy-on-Write).

Deweloperzy łatając wcześniejsza podatność z rodziny Dirty Frag, zapomnieli o funkcjach pomocniczych odpowiedzialnych za replikację pakietów podczas ich klonowania, czyli __pskb_copy_fclone oraz skb_shift. Atakujący mógł wykorzystać je do utworzenia kopii pakietów, które wskazywały na te same, wrażliwe strony pamięci, ale miały wyczyszczoną flagę SKBFL_SHARED_FRAG. 

W efekcie powstawał “specjalny” pakiet wskazujący na pamięć podręczną pliku systemowego, ale pozbawiony znaczników ochronnych. Gdy trafiał na ścieżkę odbiorczą IPSec, jądro – przekonane, że operuje na prywatnym buforze sieciowym przeprowadzało proces deszyfrowania danych, bezpośrednio w miejscu ich przechowywania. W ten sposób atakujący mógł “wstrzyknąć” własną zawartość (złośliwy kod), prosto do pamięci podręcznej zaufanego pliku wykonywalnego. A z racji tego, że plik wykonywalny posiadał flagę SUID i należał do roota, atakujący mógł wykonywać dowolne akcje w systemie z najwyższymi uprawnieniami.

<div style=”width: 100%; max-width: 800px; margin: 20px auto;”>

    <video controls width=”100%” height=”auto” style=”display: block; border-radius: 4px; box-shadow: 0 4px 10px rgba(0,0,0,0.15);”>

        <source src=”https://research.jfrog.com/img/RealTimePostImage/post/dirtyclone-cve-2026-43503/image6.mp4″ type=”video/mp4″>

    </video>

</div>

PoC. Źródło: research.jfrog.com 

Najbardziej niepokojący jest fakt, że wszelkie operacje wykonywały się bezpośrednio w pamięci RAM, nie powodując przy tym zmian na dysku twardym. W tej sytuacji proces wykrycia próby ataku jest znacząco utrudniony. 

Zgodnie z opinią badaczy z JFrog, podatne są wszystkie nowoczesne dystrybucje Linuksa (Ubuntu, Debian, RHEL, Fedora, openSUSE), które nie wdrożyły jeszcze poprawek bezpieczeństwa wydanych pod koniec maja 2026 roku. 

Jeżeli z jakiegoś powodu aktualizacje nie mogą zostać wdrożone, jako rozwiązanie tymczasowe rekomenduje się zablokowanie możliwości pozyskania uprawnień poprzez ustawienie parametru kernel.unprivileged_userns_clone=0.

Źródło: research.jfrog.com 

~_secmike