jak brak zabezpieczenia copy-on-write złamał model bezpieczeństwa jądra linux

Wielomilionowa strategia obronna zazwyczaj opiera się na założeniu, że rdzeń jądra systemu operacyjnego jest statycznym, nieprzeniknionym skarbcem. Spędzamy lata na dopracowywaniu reguł zapory ogniowej, dostawców tożsamości i skryptów wykrywania punktów końcowych, a jednak fundament architektoniczny często pozostaje najkruchszym elementem. Linux wykorzystuje optymalizację zwaną copy-on-write (kopiowanie przy zapisie), aby efektywnie zarządzać pamięcią. System ten zapewnia, że wiele procesów współdzieli tę samą pamięć fizyczną, dopóki jeden z nich nie będzie musiał jej zmodyfikować. W tym momencie jądro powinno utworzyć prywatną kopię, aby zapobiec wpływowi zmiany na innych użytkowników. W przypadku CVE-2026-31635 ta podstawowa obietnica nie została dotrzymana.

Ostatnie 48 godzin spędziłem na analizie kodu proof-of-concept wydanego dla DirtyDecrypt, znanego również jako DirtyCBC. Podatność ta jest podręcznikowym przykładem paradoksu architektonicznego. Dokładnie ten sam mechanizm, który zaprojektowano, aby uczynić jądro Linux szybkim i wydajnym pod względem pamięci, stał się mechanizmem, który pozwolił nieuprzywilejowanemu użytkownikowi na nadpisanie plików należących do roota. Jest to trzecia duża odmiana tej konkretnej logiki uszkodzenia pamięci, którą widzieliśmy w ciągu ostatnich trzech miesięcy. Przypomina mi to statek zbudowany z kadłubem, który jest nieprzenikniony z zewnątrz, ale rozpuszcza się w kontakcie z własnym paliwem wewnętrznym.

mechanika podatności rxgk pagecache

Błąd znajduje się wewnątrz funkcji rxgk_decrypt_skb. Kod ten obsługuje deszyfrowanie przychodzących buforów gniazd po stronie odbiorczej stosu sieciowego. Gdy jądro przetwarza te bufory, operuje na stronach pamięci, które czasami są współdzielone z pamięcią podręczną stron (page cache) innych procesów. W normalnych warunkach jądro Linux uruchamia operację copy-on-write przed jakimkolwiek zapisem na współdzielonej stronie. Zapobiega to przenikaniu danych z jednego procesu do przestrzeni pamięci innego.

Badacze z Zellic odkryli, że w rxgk_decrypt_skb brakowało tego zabezpieczenia COW. Gdy jądro deszyfruje dane do bufora, który okazuje się być współdzieloną stroną, zapisuje odszyfrowaną zawartość bezpośrednio do pamięci fizycznej bez wcześniejszego utworzenia prywatnej kopii. Omija to standardowe uprawnienia systemu plików i zabezpieczenia pamięci. Atakujący może zmapować wrażliwy plik, taki jak /etc/shadow lub binarny plik SUID, do swojej przestrzeni pamięci, a następnie użyć podatnej ścieżki sieciowej, aby zmusić jądro do zapisu danych do pamięci podręcznej stron tego pliku. Gdy jądro zrzuci pamięć podręczną stron na dysk, modyfikacja staje się trwała.

śledzenie rodowodu od copy fail do dirtydecrypt

DirtyDecrypt nie jest odosobnionym przypadkiem. Jest to potomek rodziny podatności, która rozpoczęła się od Copy Fail (CVE-2026-31431) w kwietniu 2026 roku. Badacze z Theori jako pierwsi zidentyfikowali, że kryptograficzny interfejs gniazd w jądrze posiadał podobne błędy logiczne. Tydzień później pojawił się Dirty Frag. Następnie pojawiła się Fragnesia, która celowała w podsystem XFRM. Każda z tych podatności ma tę samą przyczynę źródłową: brak weryfikacji własności strony przed wykonaniem zapisów na poziomie jądra.

Ta sekwencja ujawnień podkreśla systemowy problem w sposobie, w jaki jądro Linux obsługuje nowoczesne optymalizacje pamięci sieciowej. Wprowadzenie MSG_SPLICE_PAGES i innych wysokowydajnych mechanizmów zero-copy wprowadziło złożoność, z której regulacją obecna infrastruktura COW sobie nie radzi. Badacz znany jako 0xdeadbeefnetwork zauważył, że gdy tylko poprawka dla jednego wariantu trafi do publicznego drzewa, uzbrojenie kolejnego wariantu staje się standardowym ćwiczeniem dla specjalistów ds. bezpieczeństwa. Ten szybki cykl rozwoju exploitów typu n-day jest przypomnieniem, że łatka w jednym podsystemie nie gwarantuje bezpieczeństwa innego, który korzysta z podobnej logiki.

dlaczego konkretne dystrybucje pozostają na linii ognia

Wpływ CVE-2026-31635 zależy w dużej mierze od konfiguracji jądra. Podatność wymaga włączonej opcji CONFIG_RXGK. Dlatego dystrybucje takie jak Fedora, Arch Linux i openSUSE Tumbleweed są narażone na większe ryzyko. Dystrybucje te często stawiają na najnowocześniejsze funkcje i szersze wsparcie sprzętowe, co obejmuje włączanie wyspecjalizowanych modułów sieciowych i kryptograficznych, które są wyłączone w bardziej konserwatywnych wydaniach korporacyjnych, takich jak RHEL czy Debian Stable.

W środowiskach chmurowych podatność ta stanowi znaczne ryzyko dla izolacji kontenerów. Jeśli węzeł roboczy (worker node) uruchamia podatne jądro, przejęty kontener może użyć prymitywu DirtyDecrypt, aby uciec ze swojego lokalnego środowiska. Poprzez nadpisanie pamięci podręcznej stron dla współdzielonych plików binarnych lub struktur jądra, atakujący może przejść z ograniczonego poda do pełnego dostępu root na hoście. Skutecznie niszczy to model bezpieczeństwa multi-tenant, na którym polegają Kubernetes i inne orkiestrowate w celu izolacji obciążeń.

debata o killswitchu i przyszłość patchowania jądra

Liczba ujawnionych luk w jądrze wymusiła ponowne przemyślenie sposobu zarządzania bezpieczeństwem Linuksa. Sasha Levin, prominentny opiekun jądra, zaproponował ostatnio killswitch jądra. Narzędzie to pozwala administratorowi wyłączyć konkretną funkcję jądra w czasie rzeczywistym bez konieczności restartu. Jeśli w konkretnej funkcji sieciowej zostanie odkryta podatność zero-day, taka jak DirtyDecrypt, administrator może nakazać jądru zaprzestanie wykonywania tej funkcji i zwracanie zamiast niej ustalonej wartości. Działa to jak awaryjny zawór odcinający dla kadłuba statku, podczas gdy przygotowywana jest stała łatka.

Niektórzy deweloperzy obawiają się o implikacje bezpieczeństwa samego killswitcha. Jeśli atakujący uzyska wystarczające uprawnienia, aby aktywować killswitch, teoretycznie mógłby wyłączyć moduły bezpieczeństwa lub funkcje audytu. Jednak obecna rzeczywistość ekosystemu Linux jest taka, że patchowanie jest zbyt wolne w stosunku do szybkości rozwoju nowoczesnych exploitów. Killswitch zapewnia środek reaktywny dla organizacji, które nie mogą czekać na pełne testy regresyjne nowej wersji jądra. Jest to pragmatyczna odpowiedź na fakt, że nasze oprogramowanie staje się coraz zbyt złożone, by było wolne od błędów.

rocky linux i ruch w stronę przyspieszonych poprawek bezpieczeństwa

Rocky Linux przyjął inne podejście, wprowadzając dedykowane repozytorium bezpieczeństwa. Tradycyjnie dystrybucje typu downstream czekają, aż dostawcy upstream wydadzą zweryfikowaną łatkę, zanim wyślą aktualizacje do swoich użytkowników. Tworzy to okno podatności, gdy PoC jest publiczny, ale oficjalna aktualizacja utknęła w cyklu QA. Nowe repozytorium bezpieczeństwa Rocky Linux to funkcja opcjonalna (opt-in), która dostarcza pilne poprawki tak szybko, jak tylko są dostępne, nawet jeśli nie trafiły jeszcze do głównej linii jądra (mainline).

Ten ruch jest kontrowersyjny, ponieważ narusza ścisłą kompatybilność z upstreamem. Jeśli zespół Rocky Linux załata błąd, a opiekunowie upstream wybiorą później inną poprawkę, oba jądra się rozejdą. Opiekunowie uznają to ryzyko, ale wierzą, że ochrona ich użytkowników jest ważniejsza niż idealne dopasowanie wersji. Odzwierciedla to szerszą zmianę w branży w kierunku priorytetyzacji zwinności w obliczu aktywnych ataków. Dla administratorów oznacza to wybór między stabilnością tradycyjnego cyklu wydawniczego a odpornością bardziej agresywnej strategii patchowania.

łagodzenie ryzyka w środowiskach kontenerowych i bare-metal

Obrona przed CVE-2026-31635 wymaga czegoś więcej niż tylko standardowej aktualizacji. Organizacje muszą najpierw zweryfikować, czy ich systemy są w ogóle podatne. Sprawdzenie konfiguracji jądra pod kątem CONFIG_RXGK to pierwszy krok. Jeśli moduł jest włączony, ale nie jest wymagany dla Twoich zadań, wyłączenie go za pomocą czarnej listy modułów jądra (denylist) jest najskuteczniejszą natychmiastową metodą mitygacji. Eliminuje to całkowicie powierzchnię ataku, w niektórych przypadkach bez konieczności restartu.

Z perspektywy ryzyka należy założyć, że lokalni użytkownicy mają możliwość wykonania tego PoC, jeśli posiadają dostęp do powłoki (shell). Sprawia to, że ścisłe monitorowanie katalogu /etc/ oraz plików binarnych SUID jest niezbędne. Nowoczesne narzędzia bezpieczeństwa monitorujące integralność pamięci podręcznej stron mogą ostrzegać, jeśli proces próbuje zmodyfikować pliki tylko do odczytu poprzez niekonwencjonalne ścieżki pamięci. Patchowanie pozostaje złotym standardem, ale dopóki Twoja flota nie zostanie zaktualizowana, restrykcyjne profile Seccomp i polityki AppArmor mogą ograniczyć zdolność lokalnych procesów do interakcji z podatnymi funkcjami sieciowymi.

Przeprowadź audyt konfiguracji jądra i sprawdź, czy Twoja dystrybucja wydała poprawkę dla CVE-2026-31635. Organizacje korzystające z Arch lub Fedory powinny natychmiast nadać priorytet tym aktualizacjom. Jeśli zarządzasz dużą flotą serwerów Linux, rozważ długoterminowe skutki korzystania z jąder z szerokim zestawem funkcji i oceń, czy bardziej utwardzona, minimalna konfiguracja jądra jest odpowiednia dla Twojej strategii bezpieczeństwa.

Źródła

• NIST National Vulnerability Database (NVD) CVE-2026-31635 Record
• Linux Kernel Mailing List (LKML) Killswitch Proposal by Sasha Levin
• Zellic and V12 Security Technical Report on DirtyDecrypt
• Rocky Linux Security Repository Documentation
• MITRE ATT&CK Framework: Exploitation for Privilege Escalation (T1068)

Zastrzeżenie: Ten artykuł służy wyłącznie celom informacyjnym i edukacyjnym. Nie zastępuje on profesjonalnego audytu cyberbezpieczeństwa ani usługi reagowania na incydenty. Podane szczegóły techniczne mają na celu pomóc administratorom zrozumieć ryzyko i wdrożyć niezbędne mechanizmy obronne.