Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W ekosystemie OpenSSL ujawniono problem określany jako HollowByte, który może zostać wykorzystany do przeprowadzenia ataku typu denial-of-service przeciwko usługom obsługującym TLS. Błąd wynika z tego, że biblioteka we wcześniejszych wersjach potrafiła alokować bufor na podstawie długości zadeklarowanej przez klienta jeszcze przed pełną walidacją wiadomości handshake.
W praktyce oznacza to, że bardzo małe i niekompletne żądania mogą wymuszać przydział relatywnie dużych bloków pamięci. Przy odpowiedniej skali takie zachowanie może prowadzić do wzrostu zużycia pamięci procesu, fragmentacji sterty i destabilizacji serwera.
W skrócie
- HollowByte dotyczy wcześniejszych wersji gałęzi OpenSSL 3.0, 3.4, 3.5, 3.6 i 4.0.
- Poprawki zostały wprowadzone 9 czerwca 2026 roku w wersjach 3.0.21, 3.4.6, 3.5.7, 3.6.3 oraz 4.0.1.
- Problem nie otrzymał identyfikatora CVE, mimo że może prowadzić do skutecznego wyczerpywania pamięci.
- Do wywołania niepożądanego zachowania może wystarczyć 11-bajtowe żądanie TLS.
- Największe ryzyko dotyczy publicznie dostępnych usług TLS oraz środowisk z ograniczonym budżetem pamięci.
Kontekst / historia
Choć mechanizm naprawczy trafił do OpenSSL w czerwcowych wydaniach, temat został szerzej nagłośniony dopiero w lipcu 2026 roku po publikacji szczegółów przez badaczy z Okta Red Team. Nietypowy charakter sprawy wynika z tego, że poprawkę potraktowano bardziej jako utwardzenie implementacji niż klasyczną podatność bezpieczeństwa.
To ważne z perspektywy operacyjnej. W wielu organizacjach proces zarządzania ryzykiem opiera się głównie na identyfikatorach CVE, komunikatach producentów i automatycznych feedach bezpieczeństwa. Brak formalnego CVE oznacza, że część skanerów i dashboardów może nie wskazać problemu, mimo że podatna biblioteka nadal działa w środowisku produkcyjnym.
Analiza techniczna
Mechanizm HollowByte dotyczy obsługi wiadomości TLS handshake. Każda taka wiadomość zawiera nagłówek z polem długości, które informuje odbiorcę, jak duży ładunek powinien nadejść. W podatnych wersjach OpenSSL biblioteka ufała tej deklarowanej wartości zbyt wcześnie i powiększała bufor odbiorczy już po odebraniu samego nagłówka.
Atakujący może więc otworzyć połączenie, przesłać minimalny fragment danych inicjujący alokację, a następnie nie dostarczyć reszty wiadomości. Dla komunikatu ClientHello górny limit takiej alokacji wynosi około 131 KB na połączenie. Pojedyncza sesja nie musi być kosztowna, ale przy dużej liczbie równoległych połączeń efekt staje się zauważalny.
Problem pogłębia sposób zarządzania pamięcią w niektórych środowiskach opartych o glibc. Nawet jeśli połączenie zostanie zamknięte, pamięć logicznie zwolniona przez bibliotekę nie zawsze jest natychmiast oddawana systemowi operacyjnemu. Zmienność rozmiarów alokacji może dodatkowo sprzyjać fragmentacji sterty i wzrostowi RSS procesu, przez co pamięć pozostaje z perspektywy systemu „zamrożona”.
Poprawka zmienia strategię pracy z buforem wejściowym. Zamiast natychmiastowej alokacji pełnego rozmiaru zadeklarowanego przez klienta, bufor ma być powiększany stopniowo wraz z rzeczywistym napływem danych. Takie podejście znacząco ogranicza możliwość wymuszenia kosztownych alokacji wyłącznie na podstawie nagłówka wiadomości.
Konsekwencje / ryzyko
Najważniejszym skutkiem HollowByte jest ryzyko odmowy usługi przez presję na pamięć, a nie tylko przez zajmowanie połączeń. To odróżnia ten przypadek od prostszych ataków opartych na utrzymywaniu długotrwałych sesji. Nawet jeśli organizacja stosuje podstawowe timeouty, limity sesji lub reverse proxy, problem może nadal wpływać na stabilność procesu ze względu na interakcję z alokatorem pamięci.
Szczególnie narażone są:
- serwery TLS publicznie wystawione do Internetu,
- usługi obsługujące dużą liczbę jednoczesnych handshake’y,
- kontenery i instancje z niskimi limitami RAM,
- load balancery, serwery WWW i bramy API korzystające z OpenSSL,
- środowiska, w których monitorowanie ryzyka opiera się głównie na CVE.
Dodatkowym wyzwaniem jest ograniczona widoczność problemu. W dystrybucjach stosujących backporting sam numer pakietu nie zawsze jednoznacznie pokazuje, czy poprawka została już uwzględniona. To utrudnia szybką ocenę ekspozycji i może prowadzić do fałszywego poczucia bezpieczeństwa.
Rekomendacje
Podstawowym działaniem naprawczym jest aktualizacja OpenSSL do wersji zawierających poprawkę: 3.0.21, 3.4.6, 3.5.7, 3.6.3 lub 4.0.1, zależnie od używanej gałęzi. Po wdrożeniu aktualizacji należy ponownie uruchomić wszystkie usługi korzystające z biblioteki, aby mieć pewność, że nowy kod został załadowany do procesu.
Z punktu widzenia bezpieczeństwa i operacji warto wdrożyć także dodatkowe środki:
- przeprowadzić inwentaryzację usług, komponentów pośrednich i obrazów kontenerowych korzystających z OpenSSL,
- zweryfikować changelogi i biuletyny dostawcy systemu operacyjnego w przypadku backportowanych poprawek,
- monitorować RSS procesu, zużycie pamięci oraz liczbę niekompletnych handshake’y TLS,
- ustawić bardziej agresywne timeouty dla niedokończonych sesji handshake,
- wdrożyć dodatkowe limity na poziomie reverse proxy, WAF lub load balancera,
- przetestować odporność usług na scenariusze memory pressure w środowiskach preprodukcyjnych,
- rozszerzyć proces zarządzania podatnościami poza same identyfikatory CVE.
Podsumowanie
HollowByte pokazuje, że istotne zagrożenie operacyjne nie musi prowadzić do wykonania kodu, aby wymagało pilnej reakcji. W tym przypadku wystarczy niewielkie, niekompletne żądanie TLS, aby wymusić alokację pamięci i przy odpowiedniej skali doprowadzić do degradacji stabilności usług.
Największym wyzwaniem jest nie tylko samo usunięcie błędu, lecz także jego wykrycie w środowiskach polegających wyłącznie na CVE i automatycznych feedach. Organizacje powinny potraktować tę poprawkę priorytetowo i zweryfikować stan swoich wdrożeń OpenSSL niezależnie od tego, czy narzędzia bezpieczeństwa wskazują formalną podatność.