Na czym polega SCTPhantom?
SCTPhantom jest błędem typu use-after-free w implementacji protokołu SCTP (Stream Control Transmission Protocol) w jądrze Linuksa. Problem dotyczy obsługi dynamicznej rekonfiguracji adresów SCTP za pomocą mechanizmu ASCONF.
W określonej sekwencji operacji usunięcia adresu jądro zwalnia strukturę opisującą ścieżkę transportową, a następnie ponownie korzysta ze wskaźnika prowadzącego do zwolnionego obszaru pamięci. Atakujący może wykorzystać naruszenie pamięci do wykonania operacji z uprawnieniami jądra.
Podatny kod został ukończony w gałęzi Linux 2.6.25, wydanej w 2008 r. Luka przetrwała więc około 18 lat. Sam wiek błędu robi wrażenie, ale z punktu widzenia administratora ważniejszy jest inny fakt. Problem znajduje się we wspólnym jądrze, z którego korzystają także procesy uruchomione w kontenerach.
Jaki jest rzeczywisty skutek?
Badacze z Tencent Zhuque Lab opracowali działający łańcuch wykorzystania podatności. W testach użytkownik lokalny z niskimi uprawnieniami uzyskiwał pełne uprawnienia roota. Skuteczność potwierdzono między innymi w następujących środowiskach:
- Debian 13 z jądrem 6.12.95+deb13-amd64,
- Ubuntu 24.04 z jądrem 6.8.0-134-generic,
- Rocky Linux 9 i środowisko z rodziny RHEL 9 z jądrem dostawcy z gałęzi 5.14, przy załadowanej obsłudze SCTP,
- system z rodziny OpenCloudOS z jądrem 6.6.119,
- badawcze jądro Linux 7.2-rc2.
Nie oznacza to, że podatność ogranicza się do tych dystrybucji. Są to systemy, na których badacze zweryfikowali przygotowany exploit. Dokładny status konkretnego hosta zależy od konfiguracji jądra, dostępności SCTP oraz poprawek przeniesionych przez producenta dystrybucji.
Według oceny opublikowanej przez autorów badania podatność uzyskała wynik 8,5 w CVSS 4.0. Wektor ataku jest lokalny, wymaga niskich uprawnień i nie wymaga działania użytkownika. Nie jest to więc klasyczna luka pozwalająca anonimowej osobie przejąć dowolny serwer bezpośrednio z internetu. Staje się jednak bardzo poważna po uzyskaniu pierwszego dostępu do systemu, na hostach współdzielonych oraz w środowiskach kontenerowych.
Ucieczka z kontenera
Badacze przeprowadzili również atak z kontenera na system gospodarza. Kontener działał z domyślnym profilem seccomp i nie otrzymał uprawnień CAP_SYS_ADMIN ani CAP_NET_ADMIN. Sześć z ośmiu prób zakończyło się uzyskaniem uprawnień roota na hoście.
Nie oznacza to automatycznej podatności każdego klastra Kubernetes ani każdej instalacji Dockera. Na ekspozycję wpływają między innymi dostępność SCTP, możliwość korzystania z odpowiednich typów gniazd, polityka przestrzeni nazw użytkownika, profil seccomp, capabilities i mechanizmy LSM, takie jak SELinux lub AppArmor. Wynik badań przypomina jednak o podstawowej właściwości kontenerów. Procesy w kontenerze korzystają z jądra hosta, więc błąd w jądrze może naruszyć granicę izolacji, nawet gdy konfiguracja kontenera na pierwszy rzut oka nie wygląda na uprzywilejowaną.
Które wersje zawierają poprawkę?
Poprawka została włączona do głównej gałęzi jądra w commicie 9b2854f86f0b. Pierwsze poprawione wydania wskazane w komunikacie zespołu Linux kernel CVE przedstawiono poniżej.
| Gałąź jądra | Pierwsza poprawiona wersja |
|---|---|
| 6.6.y | 6.6.148 |
| 6.12.y | 6.12.101 |
| 6.18.y | 6.18.42 |
| 7.1.y | 7.1.6 |
| mainline | 7.2-rc5 |
Uwaga. Debian, Ubuntu, Red Hat, Rocky Linux i inne dystrybucje często przenoszą poprawki bezpieczeństwa do starszych wersji bazowych. Jądro nadal może zgłaszać numer 5.14 lub 6.8, a jednocześnie zawierać korektę. Może być też odwrotnie. Pozornie wysoki numer wersji nie pomoże, jeżeli uruchomione jądro pochodzi ze starego, nieaktualizowanego pakietu.
Zalecenia
- Zidentyfikować hosty linuksowe korzystające z SCTP.
- Zainstalować jądro dostarczone przez producenta dystrybucji. Aktualizacja musi obejmować poprawkę dla CVE-2026-64564.
- Sprawdzić faktycznie uruchomioną wersję.
- Jeżeli SCTP nie jest używany, rozważyć jego wyłączenie.
- Zweryfikować polityki kontenerów.
Nie zwlekać
SCTPhantom nie jest podatnością, która sama z siebie daje anonimowy dostęp z internetu. Jest jednak gotowym mechanizmem podniesienia uprawnień po uzyskaniu lokalnego dostępu, a w określonych warunkach także drogą z kontenera do hosta. W praktyce działania powinny zacząć się od hostów kontenerowych i systemów współdzielonych, następnie objąć pozostałe serwery z dostępną obsługą SCTP.