Co tak naprawdę psuje SCTPhantom

CVE-2026-64564 - nazywana przez część badaczy, którzy o niej pisali, SCTPhantom - to podatność typu use-after-free wewnątrz implementacji SCTP w jądrze Linuksa, czyli Stream Control Transmission Protocol, używanego głównie w sygnalizacji telekomunikacyjnej, niektórych systemach komunikatów finansowych oraz kilku stosach sieciowych kontenerów i klastrów. Błąd tkwi konkretnie w ASCONF, kodzie obsługującym Dynamiczną Rekonfigurację Adresów, który pozwala aktywnemu połączeniu SCTP dodawać lub usuwać adresy IP bez zamykania połączenia. CVE ogłoszono oficjalnie 4 sierpnia 2026 roku, po procesie prywatnego ujawnienia, który rozpoczął się już 12 lipca 2026 roku.

Przyczyna źródłowa to niezgodność tożsamości: gdy jądro przetwarza żądanie DEL-IP mające usunąć adres z połączenia, waliduje to żądanie na podstawie adresu źródłowego przychodzącego pakietu, podczas gdy osobny, zbuforowany wskaźnik wewnątrz jądra wciąż opiera się na adresie podanym w samym parametrze żądania. Atakujący, który skonstruuje celowo uporządkowaną sekwencję fragmentów ASCONF, może wykorzystać tę lukę między dwoma sprawdzeniami, aby zwolnić fragment pamięci jądra, podczas gdy aktywny wskaźnik wciąż na niego wskazuje - podręcznikowa definicja use-after-free i jeden z bardziej niezawodnych sposobów zamiany błędu jądra w działające wykonanie kodu.

Osiemnaście lat to nagłówek, nie lekcja

Odpowiedzialny kod sięga Linuksa 2.6.25, wydanego w grudniu 2007 roku, co czyni ten błąd bliskim 18-letniemu w chwili, gdy odnalazł go Zhuque Lab firmy Tencent. Badacze przypisują odkrycie systemowi Corvus AI, autonomicznemu, wieloagentowemu potokowi badań nad podatnościami, który zespół prowadzi wewnętrznie, a który oznaczył ścieżkę kodu ASCONF jako wartą głębszej, ręcznej weryfikacji. Ten szczegół liczy się niemal tyle samo co sam błąd: to nie przypadek znanego, ryzykownego obszaru jądra, który wreszcie doczekał się audytu, tylko naprawdę rzadko odwiedzany zakątek, którego niemal nikt nie zbadał dokładnie przez blisko dwie dekady.

Stabilne poprawki trafiły 3 sierpnia 2026 roku do gałęzi jądra 6.6.148, 6.12.101, 6.18.42 i 7.1.6, a opiekunowie dystrybucji już zaczęli włączać je do własnych drzew pakietów. To ta część historii, o której mówi każdy serwis, i zarazem część, która dla większości czytelników liczy się najmniej. Osiemnastoletnia luka między pojawieniem się błędu a jego odkryciem dowodzi, że polityka czekania na poprawkę już zawiodła po cichu przez osiemnaście lat dokładnie na tej ścieżce kodu - nie ma powodu zakładać, że kolejny nieprzejrzany zakątek jądra zostanie znaleziony szybciej, dlatego ograniczanie tego, co realnie osiągalne na danej maszynie, liczy się niezależnie od jakiejkolwiek pojedynczej daty poprawki.

Dostęp roota i ucieczka z kontenera, udowodnione

Zhuque Lab firmy Tencent zademonstrował exploit od początku do końca, a nie tylko awarię. Na systemach z Debianem 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 i OpenCloudOS zespół zamienił use-after-free w pełną eskalację uprawnień do roota z nieuprzywilejowanego konta lokalnego, a następnie użył tej samej techniki, aby uciec z kontenera do hosta w sześciu na osiem prób, bez potrzeby posiadania CAP_NET_ADMIN ani CAP_SYS_ADMIN, podwyższonych uprawnień, które większość przewodników po utwardzaniu kontenerów zakłada jako pierwszą przeszkodę dla atakującego.

Łańcuch exploitu obszedł randomizację układu przestrzeni adresowej jądra, połączył drugi use-after-free przy użyciu kontrolowanych przez atakującego kluczy uwierzytelniania SCTP i zbudował sfałszowany graf obiektów jądra, aby osiągnąć roota, wszystko bez shellcode czy łańcucha typu return-oriented programming, a więc dokładnie tych technik, które większość zabezpieczeń przed exploitami jądra ma za zadanie wychwytywać. Testy objęły wersje jądra od 5.14 aż po kandydata do wydania 7.2, a poprawka upstream trafiła jako commit 9b2854f86f0b, zanim została przeniesiona wstecz do czterech wymienionych wyżej stabilnych gałęzi.

Prosta poprawka, którą omija większość zespołów

Poprawka jest prawdziwa i warto ją zastosować, ale leczy objaw. Niemal żadna z organizacji korzystających z tych pięciu dystrybucji nie zdecydowała się świadomie włączyć SCTP - jest ono domyślnie wkompilowane wprost w główne jądro, a większość administratorów nie ma pojęcia, że w ogóle tam jest, a tym bardziej, że może do niego dotrzeć lokalny proces. To właśnie prawdziwa lekcja ukryta we własnym wątku ujawnienia badaczy na oss-security: jeden z uczestników wątku zauważył, że systemy z rodziny RHEL domyślnie trzymają SCTP wyłączony, dostarczany jako osobny pakiet kernel-modules-extra z automatycznym ładowaniem na czarnej liście, podczas gdy jądra z rodzin Debian i Ubuntu wbudowują SCTP wprost i pozwalają mu się ładować, gdy tylko zażąda tego dowolny proces. Dwa systemy mogą mieć dokładnie to samo CVE i mimo to stać przed zupełnie innym realnym ryzykiem, a różnica nie ma nic wspólnego z tym, jaką poprawkę zainstalowano.

Działanie warte podjęcia w tym tygodniu to nie czekanie na aktualizację dystrybucji, tylko sprawdzenie, czy SCTP w ogóle robi cokolwiek użytecznego na danej flocie serwerów. Polecenie lsmod | grep sctp pokazuje, czy moduł jest obecnie załadowany; sprawdzenie /etc/modprobe.d/ pod kątem istniejącego wpisu czarnej listy pokazuje, czy automatyczne ładowanie jest już zablokowane. Tam, gdzie nic legalnie nie zależy od SCTP - a na większości serwerów ogólnego przeznaczenia nie zależy nic - umieszczenie modułu na czarnej liście zamyka tę drogę niezależnie od tego, która wersja jądra kiedyś dotrze, a ten nawyk pokrywa się z tym, co polski zespół NASK/CERT Polska od dawna zaleca w przypadku każdego nieużywanego modułu jądra, nie tylko tego jednego.

Czytaj dalej: Narzędzie Twojego MSP ma drugą lukę obejścia  |  Telefon, który omija MFA w twojej firmie