strongSwan 5.9.13 z luką pre-auth DoS w module RADIUS DAE. Analiza CVE-2026-35333 - Security Bez Tabu

strongSwan 5.9.13 z luką pre-auth DoS w module RADIUS DAE. Analiza CVE-2026-35333

Cybersecurity news

Wprowadzenie do problemu / definicja

W strongSwan 5.9.13 ujawniono podatność typu denial of service, która dotyczy obsługi komunikatów RADIUS w scenariuszu Dynamic Authorization Extensions (DAE). Problem występuje wtedy, gdy aktywny jest plugin eap-radius z włączoną obsługą DAE, a demon charon nasłuchuje na porcie UDP/3799. W takich warunkach możliwe jest zdalne doprowadzenie do zablokowania wątków roboczych bez wcześniejszego uwierzytelnienia.

W skrócie

  • Podatność została oznaczona jako CVE-2026-35333.
  • Dotyczy strongSwan do wersji 5.9.13 włącznie, przy aktywnym DAE w module RADIUS.
  • Przyczyną jest niewystarczająca walidacja atrybutów RADIUS o nieprawidłowej długości.
  • Specjalnie spreparowany pakiet może wywołać nieskończoną pętlę podczas parsowania.
  • Każdy pakiet jest w stanie zablokować jeden wątek charon, co może doprowadzić do pełnej niedostępności usługi.

Kontekst / historia

strongSwan to jedno z najczęściej wykorzystywanych rozwiązań VPN/IPsec w środowiskach korporacyjnych, operatorskich i administracyjnych. Platforma obsługuje integrację z serwerami RADIUS, a mechanizm DAE umożliwia dynamiczne operacje autoryzacyjne, co w wielu wdrożeniach ma znaczenie operacyjne.

Opis problemu wskazuje, że podatne są instalacje, w których plugin eap-radius został zbudowany z obsługą DAE i funkcja ta pozostaje aktywna w konfiguracji. Publiczne ujawnienie błędu nastąpiło pod koniec maja 2026 roku wraz z technicznym opisem oraz przykładowym kodem proof-of-concept, co podnosi ryzyko szybkiego wykorzystania podatności w praktyce.

Analiza techniczna

Źródłem problemu jest funkcja odpowiedzialna za enumerację atrybutów RADIUS w komponencie libradius. Mechanizm iteracji akceptował rekordy, których pole długości było mniejsze niż minimalny rozmiar struktury atrybutu. W szczególności wartość length == 0 powodowała, że iterator nie przesuwał się do kolejnego elementu, przez co wykonywał pętlę bez postępu.

Dodatkowym problemem był sposób obliczania długości danych atrybutu, który mógł prowadzić do niedomiaru typu całkowitego. W efekcie wadliwy pakiet nie tylko destabilizował logikę parsowania, ale także utrzymywał zajęty wątek roboczy procesu odpowiedzialnego za obsługę żądań.

Istotny z perspektywy bezpieczeństwa jest fakt, że ta ścieżka parsowania była wykorzystywana jeszcze przed zakończeniem pełnej walidacji integralności komunikatu. Oznacza to, że atakujący nie musi znać sekretu współdzielonego DAE, aby wywołać efekt odmowy usługi. Właśnie dlatego podatność klasyfikowana jest jako pre-auth DoS.

Praktyczny scenariusz ataku jest stosunkowo prosty. Napastnik wysyła krótki pakiet UDP zawierający nagłówek RADIUS oraz pojedynczy atrybut o zerowej długości. Każdy taki pakiet może zablokować jeden worker charon. Seria pakietów pozwala stopniowo wyczerpać całą pulę wątków, powodując pełną niedostępność usługi DAE.

Poprawka przygotowana przez projekt strongSwan polega na dodaniu jawnej kontroli odrzucającej atrybuty o długości mniejszej niż minimalny rozmiar nagłówka atrybutu RADIUS. Dzięki temu nieprawidłowe rekordy są zatrzymywane na etapie walidacji i nie trafiają do dalszego przetwarzania.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest zdalna odmowa usługi bez uwierzytelnienia. W środowiskach, gdzie DAE jest osiągalne sieciowo z mniej zaufanych segmentów, atak może szybko doprowadzić do wyczerpania zasobów procesu charon. To z kolei może zakłócić działanie mechanizmów dynamicznej autoryzacji oraz komponentów zależnych od obsługi RADIUS.

Ryzyko rośnie w infrastrukturach o wysokiej dostępności, szczególnie na styku sieci i w środowiskach VPN obsługujących wielu użytkowników lub zautomatyzowane procesy sieciowe. Chociaż luka nie wskazuje na wykonanie kodu ani bezpośredni wyciek danych, jej wpływ operacyjny może być znaczący, zwłaszcza przy publicznie dostępnym opisie exploita.

Rekomendacje

W pierwszej kolejności organizacje powinny ustalić, czy korzystają z pluginu eap-radius z aktywną obsługą DAE. Jeśli funkcja nie jest wymagana, najlepszym krokiem będzie jej wyłączenie. Jeżeli jednak DAE pozostaje niezbędne, priorytetem powinno być wdrożenie wersji zawierającej poprawkę lub wykonanie odpowiedniego backportu.

  • Ograniczyć dostęp do UDP/3799 wyłącznie do zaufanych serwerów RADIUS i segmentów administracyjnych.
  • Zastosować reguły filtracji na zaporach i listach ACL.
  • Monitorować proces charon pod kątem nietypowego wzrostu użycia CPU przez wątki robocze.
  • Wdrożyć alerty wykrywające anomalie w ruchu RADIUS, zwłaszcza krótkie lub niepoprawne pakiety.
  • Przeprowadzić przegląd konfiguracji wszystkich komponentów korzystających z DAE.
  • Przygotować procedury restartu i odtworzenia usługi w razie wyczerpania workerów.

Z perspektywy zespołów SOC warto również wdrożyć reguły detekcyjne dla ruchu zawierającego atrybuty RADIUS o długości mniejszej niż minimalna wartość przewidziana przez protokół. Taka kontrola na brzegu sieci może ograniczyć skuteczność prób eksploatacji jeszcze przed dotarciem pakietów do podatnej usługi.

Podsumowanie

CVE-2026-35333 pokazuje, jak pozornie niewielki błąd w parsowaniu danych wejściowych może doprowadzić do poważnej odmowy usługi w systemie bezpieczeństwa sieciowego. W tym przypadku niewystarczająca walidacja długości atrybutów RADIUS umożliwia blokowanie wątków charon poprzez wysyłanie spreparowanych pakietów Access-Request.

Organizacje korzystające z strongSwan i funkcji DAE powinny potraktować problem priorytetowo. Kluczowe działania obejmują weryfikację ekspozycji usługi, wdrożenie poprawki oraz ograniczenie dostępu sieciowego do interfejsu DAE wyłącznie do zaufanych systemów.

Źródła