OpenSSL łata lukę HollowByte: groźny atak DoS przez wyczerpanie pamięci - Security Bez Tabu

OpenSSL łata lukę HollowByte: groźny atak DoS przez wyczerpanie pamięci

Cybersecurity news

Wprowadzenie do problemu / definicja

OpenSSL usunął podatność określaną jako HollowByte, która umożliwia przeprowadzenie ataku typu denial-of-service przez stopniowe wyczerpywanie pamięci procesu jeszcze przed zakończeniem uzgadniania połączenia TLS. Problem dotyczył sposobu obsługi deklarowanego rozmiaru wiadomości na wczesnym etapie handshake, co mogło wpływać na szeroką grupę usług korzystających z tej biblioteki kryptograficznej.

Choć luka nie prowadzi do obejścia szyfrowania ani zdalnego wykonania kodu, jej znaczenie operacyjne jest wysokie. W praktyce atakujący mógł relatywnie niskim kosztem doprowadzić do degradacji wydajności lub utraty dostępności usług sieciowych opartych na OpenSSL.

W skrócie

  • HollowByte to podatność DoS związana z nieprawidłową alokacją pamięci podczas handshake TLS.
  • Luka została odkryta przez red team firmy Okta.
  • Atak wykorzystuje niewielki, spreparowany pakiet deklarujący większy rozmiar danych niż faktycznie przesyłany.
  • Skutkiem może być trwały wzrost zużycia pamięci procesu i niedostępność usługi.
  • Poprawki trafiły do OpenSSL 4.0.1 oraz zostały przeniesione do gałęzi 3.6.3, 3.5.7, 3.4.6 i 3.0.21.

Kontekst / historia

OpenSSL pozostaje jednym z najważniejszych komponentów infrastruktury bezpieczeństwa w środowiskach Linux, Unix i wielu aplikacjach serwerowych. Biblioteka obsługuje warstwę TLS w serwerach WWW, reverse proxy, językach uruchomieniowych, bazach danych i licznych usługach middleware, dlatego nawet podatność ograniczona do wpływu na dostępność może mieć bardzo szerokie skutki.

W przypadku HollowByte problem nie wynikał z błędu kryptograficznego, lecz z zaufania do danych wejściowych przekazywanych przez klienta na bardzo wczesnym etapie połączenia. To przykład sytuacji, w której pozornie techniczny szczegół zarządzania pamięcią staje się skutecznym wektorem ataku na odporność operacyjną systemów produkcyjnych.

Analiza techniczna

Źródłem luki był sposób, w jaki starsze wersje OpenSSL prealokowały bufor odbiorczy na podstawie długości wiadomości zadeklarowanej w 4-bajtowym nagłówku komunikatu handshake. Zamiast zwiększać bufor stopniowo wraz z realnym napływem danych, biblioteka przygotowywała pamięć z wyprzedzeniem, ufając wartości podanej przez klienta.

Napastnik mógł wysłać bardzo krótki pakiet inicjujący, liczący około 11 bajtów, który deklarował znacznie większy rozmiar wiadomości. W efekcie serwer alokował bufor sięgający nawet około 131 KB na pojedyncze połączenie, mimo że dalsze dane nie były dostarczane. Następnie wątek roboczy oczekiwał na brakujące bajty, pozostając zablokowany na niepełnym strumieniu.

Teoretycznie pamięć była później zwalniana po zamknięciu połączenia, ale w praktyce problem wzmacniało zachowanie alokatora pamięci w GNU C Library. Mniejsze i średnie przydziały nie zawsze są natychmiast oddawane systemowi operacyjnemu, lecz pozostają w puli procesu. Przy wielu połączeniach z losowymi deklarowanymi rozmiarami utrudnia to skuteczne ponowne wykorzystanie segmentów pamięci, prowadząc do fragmentacji i trwałego wzrostu zużycia RAM.

Z punktu widzenia obrony istotne jest także to, że atak nie wymaga ogromnej liczby jednoczesnych sesji. Oznacza to, że klasyczne ograniczenia liczby połączeń lub proste mechanizmy rate limiting mogą nie być wystarczające. Poprawka zmienia logikę biblioteki tak, aby bufor zwiększał się dopiero wraz z faktycznym napływem danych, a nie jedynie na podstawie deklarowanej długości wiadomości.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem HollowByte jest utrata dostępności usług korzystających z podatnych wersji OpenSSL. W zależności od architektury środowiska problem może objawiać się jako wzrost zużycia pamięci, spadek responsywności procesu, blokowanie workerów, pogorszenie wydajności całego hosta lub całkowite zawieszenie usługi wymagające restartu.

Podwyższone ryzyko dotyczy zwłaszcza środowisk publicznie wystawionych do internetu, obsługujących dużą liczbę krótkich połączeń TLS, działających na współdzielonych hostach z ograniczoną pamięcią oraz wdrożeń opartych na kontenerach i limitach cgroup. Narażone mogą być serwery WWW, reverse proxy, aplikacje wykorzystujące Node.js, Python, Ruby i PHP, a także wybrane implementacje baz danych i innych usług zależnych od OpenSSL.

  • przestoje usług i naruszenie SLA,
  • wzrost kosztów operacyjnych związanych z analizą incydentu,
  • trudniejsze diagnozowanie problemów wydajnościowych,
  • pogorszenie stabilności hostów współdzielących zasoby,
  • konieczność awaryjnych restartów lub przełączeń usług.

Rekomendacje

Podstawowym działaniem naprawczym jest szybka aktualizacja OpenSSL do wersji zawierających poprawkę. Organizacje powinny zweryfikować nie tylko pakiety systemowe, lecz także komponenty aplikacyjne, które mogą statycznie lub dynamicznie linkować podatne wydania biblioteki.

  • zinwentaryzować wszystkie systemy i aplikacje korzystające z OpenSSL,
  • sprawdzić obrazy kontenerowe, pakiety bazowe i zależności pośrednie,
  • przeprowadzić restart usług po wdrożeniu aktualizacji, jeśli jest wymagany,
  • monitorować nietypowy wzrost pamięci procesów obsługujących TLS,
  • analizować krótkie i niedokończone sesje TLS oraz anomalie handshake,
  • wdrożyć alerty na wzrost liczby połączeń kończących się przed przesłaniem pełnych danych,
  • stosować warstwowe mechanizmy ochrony przed DoS na poziomie sieci, reverse proxy i load balancerów.

Jako środki tymczasowe można rozważyć zaostrzenie timeoutów połączeń, tuning limitów zasobów procesów, izolację krytycznych usług oraz dodatkowe monitorowanie fragmentacji pamięci. Nie powinny one jednak zastępować aktualizacji, ponieważ źródło problemu znajduje się w samej logice OpenSSL.

Podsumowanie

HollowByte pokazuje, że nawet niewielki błąd w obsłudze metadanych protokołu może przełożyć się na skuteczny atak na dostępność usług. W tym przypadku zaufanie do deklarowanego rozmiaru danych podczas handshake prowadziło do zbędnych alokacji pamięci, które przy odpowiednim wzorcu ruchu mogły trwale obciążyć proces i unieruchomić serwer.

Dla zespołów bezpieczeństwa i administratorów kluczowe są trzy działania: identyfikacja zależności od OpenSSL, szybka aktualizacja do poprawionych wersji oraz rozszerzenie monitoringu o anomalie pamięci i nietypowe zachowanie połączeń TLS. Mimo że luka nie umożliwia bezpośrednio wykonania kodu, jej wpływ na ciągłość działania środowiska jest istotny i wymaga priorytetowej reakcji.

Źródła