W ostatnim czasie mamy do czynienia z prawdziwym wysypem podatności określanych jako „krytyczne”. Nie zdążyliśmy zapomnieć o php2shell, Node2Shell czy sytuacji związanej z certyfikatami eMudhra, a już pojawiła się nowa podatnośćw samym kernelu Linux. CVE-2026-98432 dotyczy błędu przy obsłudze protokołu TCP, gdzie równoczesne przetwarzanie ponowionych połączeń powoduje znany programistom problem określany jako race condation. Udane wykorzystanie tego błędu może skutkować atakiem DoS, naruszeniem pamięci, a choćby zdalnym wykonaniem kodu. Można założyć, iż scenariusz ataku jest zależny od umiejętności atakującego. Jednak do tej pory nie powstał żaden ogólnodostępny exploit – wiemy jedynie, iż Claude poradził sobie z opracowaniem i przeprowadzeniem ataku – szczegóły znajdują się w rozdziale piątym, ale warto zapoznać się także z innymi opisanymi lukami.
Niestety ponownie jest to podatność „krytyczna” głównie z nazwy. Oczywiście media branżowe podchwyciły temat i zaczęły publikować niepokojące artykuły. Tymczasem wiele źródeł wskazuje, iż realnie podatne są usługi wykorzystujące rozszerzenie multipath TCP (MPTCP) – co nie jest standardową praktyką i znalezienie serwera wystawiającego cokolwiek z użyciem MPTCP będzie trudne. Tradycyjne serwery HTTP nie powinny być podatne. Przykładowo nginx wspiera opcję multipath, ale nie jest to domyślna konfiguracja i bardzo wątpliwe, aby administratorzy zmieniali akurat te ustawienia.
Z drugiej strony mamy informacje od zespołu Ubuntu, iż zablokowanie wspomnianego rozszerzenia to niepełne rozwiązanie problemu, bo opracowany przez Claude exploit używa MPTCP i nie stwierdzono alternatywnego podejścia dla ataku na samo TCP, co rzekomo nie oznacza, iż takowe nie istnieje. Niestety w takim wypadku jedynie aktualizacja kernela będzie kompleksowym zabezpieczeniem – i akurat tak się złożyło, iż to właśnie Ubuntu wciąż nie wydało aktualizacji, pomimo istnienia poprawki w kodzie kernela od przeszło miesiąca.
Na samą poprawkę składają się zmiany w dwóch liniach w pliku net/ipv4/af_inet.c.
Rzecz jasna nikt nie chciałby kompilować kernela we własnym zakresie dla systemów działających w środowisku produkcyjnym. Należało oczekiwać na udostępnienie oficjalnych aktualizacji przez dostawców danych systemów operacyjnych. Jako pierwsi zadbali o to twórcy Debiana już dwa tygodnie temu. Z kolei 1 listopada wydano aktualizacje dla systemów RHEL i pokrewnych. Użytkownicy Ubuntu muszą jeszcze cierpliwie poczekać albo wprowadzić tymczasową mitygację przedstawioną m.in. na blogu AlmaLinux.
Mimo wszystko na ten moment ryzyko skutecznego użycia podatności jest najpewniej znikome. Świadczyć o tym może brak udostępnionego exploita, tym bardziej iż sprawa jest znana od kilku dni. Prawdopodobnie więc przeprowadzenie ataku jest bardzo złożone i raczej nie powinniśmy mieć powodów do obaw.
Fakt, iż okrycie luki nastąpiło po dziesięciu latach od dodania problematycznego kodu do kernela w wersji 4.4 może być powiązany z wiadomym zastosowaniem AI w testach bezpieczeństwa. Temat ten jest obecny przy wielu „krytycznych” podatnościach, które pojawiły się w ciągu mijającego roku, więc nie będziemy się nim szczegółowo zajmować.
Zawsze warto jednak przypomnieć podstawową zasadę, która sprowadza się do minimalizacji dostępu. Powinniśmy maksymalnie redukować ilość usług dostępnych z zewnątrz. Tutaj najlepiej sprawdza się podejście wykorzystania jednego punktu stanowiącego reverse proxy do usług działających w bezpiecznej sieci wewnętrznej. Może to być zwykły nginx, HAProxy czy komercyjne rozwiązanie – nie ma to większego znaczenia. Jedną usługę łatwiej zabezpieczyć, a w razie faktycznego zagrożenia po prostu wyłączyć.
Należy też realnie oceniać ryzyko. choćby w przypadku tej konkretnej podatności największe zagrożenie będzie pochodzić z zewnątrz. jeżeli wszystkie nasze systemy działają wyłącznie lokalnie, to nie możemy mówić o rzeczywistym ryzyku ani tym bardziej podejmować restrykcyjnych działań, takich jak wyłączenie kluczowych usług w przedsiębiorstwie. Podobne reakcje byłyby nieprofesjonalne, a ponadto mogłyby mieć negatywne następstwa. Dodatkowo sprawca ataku w lokalnej sieci mógłby zostać gwałtownie wykryty, co nie zawsze ma miejsce w przebiegu prawdziwych ataków działających w ramach Internetu.
Aktualizacje warto przeprowadzać regularnie, bo w razie pilnej konieczności wdrożenia poprawek dla systemu działającego i nieaktualizowanego od roku mogą pojawić się problemy, których rozwiązanie będzie wymagać czasu. Zawsze też trzeba zapewnić sobie sprawną możliwość przywrócenia stanu sprzed aktualizacji, bo nie możemy mieć całkowitej pewności, iż choćby oficjalne aktualizacje nie okażą się wadliwe.
