Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
HollowByte to nowo ujawniona technika ataku typu denial of service wymierzona w serwery korzystające z OpenSSL do obsługi połączeń TLS. Istota problemu polega na tym, że podatne implementacje alokują pamięć na podstawie długości zadeklarowanej w nagłówku komunikatu handshake, zanim otrzymają pełną zawartość wiadomości. Dzięki temu napastnik może wymuszać kosztowne operacje po stronie serwera przy użyciu minimalnego ruchu sieciowego.
W skrócie
Atak HollowByte pozwala nieuwierzytelnionemu podmiotowi stopniowo zwiększać zużycie pamięci procesu poprzez wielokrotne inicjowanie połączeń TLS i wysyłanie krótkiego, 11-bajtowego pakietu z zawyżoną deklaracją długości danych. W efekcie serwer rezerwuje pamięć, oczekując na dalszy payload, który nigdy nie nadchodzi. Problem może prowadzić do degradacji wydajności, fragmentacji sterty i trwałego wzrostu RSS procesu nawet po zakończeniu ataku.
- atak nie wymaga wysokiej przepustowości,
- może być prowadzony równolegle na wielu sesjach TLS,
- wpływa głównie na dostępność i stabilność usług,
- poprawki trafiły do nowszych wersji OpenSSL w kilku wspieranych gałęziach.
Kontekst / historia
OpenSSL pozostaje jednym z kluczowych komponentów współczesnej infrastruktury internetowej. Biblioteka jest powszechnie wykorzystywana przez serwery WWW, reverse proxy, API, bazy danych, aplikacje kontenerowe i liczne usługi uruchamiane w systemach Linux oraz Unix. Z tego powodu każda podatność wpływająca na przebieg negocjacji TLS może mieć szeroki zasięg operacyjny.
HollowByte został opisany jako słabość związana nie z wykonaniem kodu czy wyciekiem danych, lecz z nieefektywną obsługą pamięci podczas przetwarzania niekompletnych komunikatów handshake. Tego rodzaju podatności często bywają niedoszacowane, ponieważ nie prowadzą bezpośrednio do przejęcia systemu, ale mogą skutecznie obniżać dostępność usług publicznych i wewnętrznych.
Analiza techniczna
Źródło problemu znajduje się w sposobie obsługi komunikatów TLS Handshake. Każda wiadomość handshake zawiera 4-bajtowy nagłówek, w którym 3 bajty określają długość dalszej części komunikatu. W podatnych wersjach OpenSSL serwer ufa tej wartości zbyt wcześnie i dokonuje alokacji bufora zgodnie z deklarowanym rozmiarem jeszcze przed odebraniem całej wiadomości.
Napastnik może więc zestawić połączenie TLS, wysłać krótki komunikat z dużą zadeklarowaną długością danych i przerwać transmisję dalszego payloadu. Serwer utrzymuje przydzieloną pamięć i oczekuje na brakujące dane, co przy wielu równoległych połączeniach prowadzi do sztucznego wzrostu zużycia zasobów. Taki model ataku jest asymetryczny: koszt po stronie atakującego pozostaje bardzo niski, natomiast koszt po stronie serwera rośnie nieproporcjonalnie.
Znaczenie ma również zachowanie alokatora pamięci. Nawet jeśli część buforów zostanie zwolniona po zamknięciu sesji, pamięć nie zawsze wraca od razu do systemu operacyjnego. W praktyce może to powodować utrzymywanie przydzielonych obszarów w procesie, pogłębianie fragmentacji sterty i trwały wzrost RSS. Przy atakach prowadzonych falami, z różnymi deklarowanymi rozmiarami, odzyskiwanie pamięci staje się jeszcze trudniejsze, a pełna normalizacja bywa możliwa dopiero po restarcie usługi.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem HollowByte jest zagrożenie dla dostępności usług. W środowiskach o ograniczonych zasobach pamięci atak może stosunkowo szybko doprowadzić do wzrostu opóźnień, niestabilności działania, aktywacji mechanizmów OOM i czasowej niedostępności aplikacji. W większych środowiskach skutki mogą narastać wolniej, ale nadal przekładać się na spadek wydajności i stabilności.
Ryzyko dotyczy szczególnie infrastruktury, w której OpenSSL odpowiada za terminację TLS przed warstwą biznesową. Obejmuje to między innymi serwery NGINX i Apache, bramy API, reverse proxy, aplikacje uruchamiane w kontenerach oraz komponenty chmurowe bazujące na standardowych pakietach systemowych. Dodatkowym wyzwaniem jest możliwość prowadzenia ataku poniżej typowych progów alarmowych związanych z wolumenem ruchu, co może utrudniać szybką detekcję przez SOC i zespoły operacyjne.
Rekomendacje
Priorytetem powinno być zidentyfikowanie systemów korzystających z podatnych wersji OpenSSL, zarówno bezpośrednio, jak i pośrednio przez pakiety dystrybucyjne, obrazy kontenerowe oraz zależności aplikacyjne. Następnie należy zaplanować aktualizację do wersji zawierających poprawkę, odpowiednio dla używanej gałęzi.
- przeprowadzić inwentaryzację bibliotek OpenSSL w środowisku,
- zaktualizować pakiety do wersji zawierających poprawkę,
- ograniczyć liczbę równoległych połączeń TLS z pojedynczych źródeł,
- skrócić timeouty dla niekompletnych handshake’y,
- monitorować RSS oraz anomalie pamięci w procesach obsługujących TLS,
- korelować zdarzenia związane z dużą liczbą niedokończonych sesji,
- wykorzystać reverse proxy, WAF lub usługi anty-DDoS zdolne do wykrywania nietypowych wzorców handshake.
Warto również zweryfikować, czy po wdrożeniu aktualizacji konieczny jest restart usług w celu odzyskania pamięci i przywrócenia stabilnego profilu pracy. Organizacje korzystające z pakietów systemowych powinny potwierdzić, że poprawka została dostarczona przez ich dostawcę w używanym kanale aktualizacji. Dobrą praktyką jest także wykonywanie testów odpornościowych obejmujących niekompletne komunikaty handshake i niskowolumenowe scenariusze DoS.
Podsumowanie
HollowByte pokazuje, że nawet pozornie niewielka słabość w obsłudze handshaku TLS może przełożyć się na realne ryzyko operacyjne dla szerokiej infrastruktury. Mechanizm ataku wykorzystuje zaufanie do długości zadeklarowanej w nagłówku, aby wymuszać kosztowne alokacje pamięci przy użyciu minimalnego pakietu wejściowego. W efekcie organizacje mogą mierzyć się z trwałym wzrostem zużycia pamięci, fragmentacją sterty i pogorszeniem dostępności usług.
Najskuteczniejszą odpowiedzią pozostaje szybka aktualizacja OpenSSL, weryfikacja zależności w łańcuchu dostaw oprogramowania oraz wzmocnienie monitoringu pod kątem anomalii w warstwie TLS i pamięci procesów. Choć podatność nie prowadzi bezpośrednio do kradzieży danych ani zdalnego wykonania kodu, jej znaczenie biznesowe i operacyjne jest wysokie.
Źródła
- BleepingComputer — https://www.bleepingcomputer.com/news/security/hollowbyte-ddos-flaw-bloats-openssl-server-memory-with-11-byte-payload/
- OpenSSL Library — Release and Advisory Timeline — https://mirror.openssl-library.org/news/timeline/
- OpenSSL Library — Downloads — https://www.openssl-library.org/source/