Wystartowała Akademia NIS2/KSC2! Można jeszcze dołączyć do końca lipca!
Konferencja Mega Sekurak Hacking Party w Krakowie – 26-27 października!
Bezpłatne szkolenie: AI dla admina. Top 5 zadań, które zrobisz szybciej
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.
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
unprivileged_userns_clone to nie jest parametr standardowego kernela. Występuje w patchu linux-hardened i tych dystrybucjach, które go stosują.
Zamiast niego można użyć user.max_user_namespaces=0.
Nie do końca. unprivileged_userns_clone pozwala na wyłączenie możliwości tworzenia user-namespace’ów przez zwykłych użytkowników. Natomiast ustawienie user.max_user_namespaces=0 wyłącza całkowicie możliwość ich tworzenia, nawet dla roota, co skutecznie uniemożliwia uruchamianie nieuprzywilejowanych kontenerów, a to z kolei może być wymagane przez niektóre usługi startowane z systemd.
Oczywiście w sytuacji tak poważnego buga i na przyszłość, należy się zastanowić, czy powinno się mieć konta niezaufanych użytkowników na tym samym hoście, na którym uruchamiane są kontenery.
Root nie musi używać flagi CLONE_NEWUSER przy tworzeniu kontenerów.
Nawet jak na hoście nie będzie niezaufanych użytkowników, to w usłudze uruchomionej w kontenerze może zdarzyć się RCE. Jeżeli user namespaces będą włączone, to taki kod RCE może wykorzystać podatność w kernelu. Dlatego user namespaces powinny być bezwzględnie wyłączone zawsze i wszędzie i mam nadzieję, że kiedyś zostaną usunięte z jądra. Tego nie da się poprawić. Trzeba by było od zera napisać wszystkie uprzywilejowane funkcje, bo te obecne były pisane przy założeniu, że będą wykorzystywane wyłącznie przez roota.
Nie rozumiesz idei user-namespace i tego jak działają. Właśnie po to jest CLONE_NEWUSER, żeby je tworzyć. Oczywiście, że root nie musi używać tej flagi, tylko wtedy nie utworzy osobnej przestrzeni. W przypadku zwykłego użytkownika działa to dokładnie tak samo, więc nie ma to znaczenia i nie o tym tu jest mowa. Natomiast to, czy prawo użycia tej flagi powinien mieć tylko root czy też zwykli użytkownicy, to jest kwestia nawet nie tyle ogólnej dyskusji co decyzji na poziomie każdego konkretnego systemu, bo w różnych przypadkach różne są wymagania. Na pewno jednak kernel powinien dawać możliwość dynamicznego blokowania/odblokowywania tego w danym systemie w zależności od uznania administratora i to właśnie robi parametr unprivileged_userns_clone. Szkoda tylko, że nie ma go w bazowym kernelu i trzeba do tego zakładać patcha.
Natomiast same user-namespaces są bardzo dobrym pomysłem i rozwiązaniem, które pozwala mocno zabezpieczyć kontenery, bo nawet jak jakimś cudem uda się procesowi wyskoczyć z kontenera, to na hoście będzie miał uprawnienia zwykłego użytkownika, a nie roota. Bez user-namespace’ów byłoby wtedy już po systemie. Na szczęście developerzy kernela na ogół wiedzą co robią i nie myślą tak jak ty, więc nie sądzę żeby user-namespaces zostały usunięte.
Wiem, że nie na temat, ale trwa seria ataków na strony postawione na Joomli. Atakowane są m.in. komponenty sppagebuilder, pagebuilderck, jce editor, nrnetwork. Logi wskazują na rożne serwery proxy z całego świata. Ataki automatyczne.
Odpowiadam użytkownikowi Zenon (nie widzę pod jego postem przycisku Odpowiedz): CLONE_NEWUSER jest po to, żeby nieuprzywilejowany użytkownik mógł utworzyć kontener i mieć w nim uprawnienia roota. Prawdziwy root nie potrzebuje tej flagi i jak najbardziej może tworzyć kontenery. Taki Docker uruchamiany z roota może tworzyć kontenery nawet z parametrami user.max_user_namespaces=0 oraz kernel.unprivileged_userns_clone=0. Procesy w tych kontenerach mogą być (i zwykle są) nieuprzywilejowane. Jeżeli w kontenerze nie jest za dużo podmontowane z hosta (np. socket API Dockera), to wyskoczenie z niego może być bardzo trudne.