OpenSSL HollowByte: 11 bajtów może wyczerpać RAM

HollowByte to nietypowy przypadek podatności na odmowę usługi w OpenSSL: badacze Okta Red Team wykazali, że nieuwierzytelniony klient może sprowokować nieproporcjonalnie dużą alokację pamięci przy pomocy zaledwie 11 bajtów przygotowanego ruchu TLS. Problem nie potrzebuje poprawnego certyfikatu, konta ani zakończonego handshake. Najważniejszą lekcją nie jest jednak sama liczba bajtów, lecz asymetria kosztu: napastnik wysyła niemal nic, a serwer rezerwuje pamięć i utrzymuje ją dla wielu niedokończonych połączeń.

Okta opisała badanie HollowByte 16 lipca 2026 roku, a temat trafił do szerszych alertów branżowych 20 lipca. OpenSSL potraktował zmianę jako wzmocnienie odporności, a nie klasyczną lukę bezpieczeństwa: nie opublikowano CVE ani standardowego advisory. Brak identyfikatora CVE nie oznacza jednak braku ryzyka operacyjnego. Administrator powinien ocenić realną ekspozycję swoich terminatorów TLS, wykorzystaną wersję biblioteki, limity połączeń oraz zachowanie alokatora pamięci.

Co dokładnie potwierdzili badacze

Problem występuje na początku negocjacji TLS. Rekord zawiera czterobajtowy nagłówek ClientHello, w którym zadeklarowana długość wiadomości może być znacznie większa niż dane rzeczywiście dostarczone w pierwszym pakiecie. OpenSSL na wczesnym etapie rezerwował bufor odpowiadający deklarowanej długości, zanim otrzymał całą wiadomość. Połączenie pozostawało otwarte i czekało na resztę danych, a pamięć była zajęta.

W opisanym wariancie rekord miał 11 bajtów, natomiast pojedyncze połączenie mogło doprowadzić do przydzielenia około 131 KB. Ten mnożnik nie wygląda groźnie dla jednej sesji, ale tysiące równoległych, powolnych połączeń zmieniają rachunek. Atak nie polega na wysłaniu dużego pliku ani wykonywaniu kodu. Wykorzystuje różnicę między tanim żądaniem po stronie klienta i droższym stanem utrzymywanym po stronie usługi.

W laboratorium z limitem 1 GB proces został zakończony przez mechanizm OOM, gdy około 547 MB pozostawało w zamrożonych i pofragmentowanych obszarach pamięci. W teście 16 GB, ograniczonym maksymalną liczbą połączeń, proces utrzymywał około jednej czwartej pamięci systemu. To wyniki środowiska badawczego, a nie gwarantowany efekt na każdej instalacji. Rzeczywisty rezultat zależy od serwera, limitów deskryptorów, timeoutów, systemu operacyjnego, alokatora i sposobu, w jaki aplikacja używa OpenSSL.

Dlaczego pamięć nie wracała od razu do systemu

Drugą częścią HollowByte jest fragmentacja sterty. Nawet gdy część połączeń zostaje zamknięta, zwolnione małe obszary nie muszą tworzyć ciągłego bloku, który biblioteka glibc może oddać systemowi operacyjnemu. Proces widzi pamięć jako dostępną do ponownego użycia, ale wartość RSS pozostaje wysoka. Z punktu widzenia kontenera, cgroup albo limitu hosta zasób nadal jest zajęty.

To wyjaśnia, dlaczego samo skrócenie timeoutu nie musi natychmiast przywrócić usługi do bezpiecznego stanu. Timeout ogranicza czas utrzymywania nowego połączenia, lecz nie usuwa skutków fragmentacji ani nie zmienia wczesnego wzorca alokacji. Restart procesu może chwilowo zwolnić RAM, ale bez poprawionej biblioteki ponownie wystawi usługę na tę samą asymetrię.

HollowByte jest więc dobrym przykładem, dlaczego monitoring powinien obejmować nie tylko procent użycia pamięci. Potrzebne są także liczba otwartych handshake’ów, tempo nowych połączeń, czas sesji w stanie oczekiwania, liczba workerów, błędy alokacji i restarty inicjowane przez OOM.

W środowisku wielodostępnym obserwuj również wpływ sąsiednich workloadów. Wspólna pula pamięci może sprawić, że presja wywołana na terminatorze TLS pogorszy bazę danych, kolejkę lub usługę uwierzytelniania. Limity cgroup, podział węzłów i rezerwy systemowe ograniczają promień rażenia, choć nadal nie naprawiają zachowania biblioteki.

Poprawka: bufor rośnie razem z danymi

OpenSSL zmienił logikę tak, aby bufor nie był od razu powiększany do całej długości zadeklarowanej przez niezaufanego klienta. Dane są pobierane i buforowane przyrostowo. Dzięki temu koszt po stronie serwera lepiej odpowiada liczbie bajtów faktycznie odebranych z sieci.

Zmiany są publicznie widoczne w pull requestach #30792, #30793 i #30794. Mechanizm trafił do wydań OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 oraz 3.0.21. Jeżeli dystrybucja Linuksa utrzymuje starszy numer bazowy, mogła przenieść poprawkę jako backport. Sam ciąg wersji nie wystarczy wtedy do oceny; trzeba sprawdzić changelog pakietu i biuletyn dostawcy.

Nie należy też mechanicznie szukać numeru CVE. Projekt OpenSSL zaklasyfikował zmianę jako hardening. Skaner, który raportuje wyłącznie CVE, może jej nie pokazać, nawet gdy w środowisku działa niepoprawiony kod. To argument za połączeniem zarządzania podatnościami z obserwacją upstreamu i inwentaryzacją komponentów.

Które systemy mogą być narażone

OpenSSL jest biblioteką, a nie pojedynczym serwerem. Może działać w reverse proxy, bramie API, VPN, brokerze wiadomości, serwerze pocztowym, agencie, aplikacji wbudowanej albo niestandardowej usłudze. Jednak obecność pakietu na dysku nie dowodzi ekspozycji. Czasem publiczny TLS kończy się na load balancerze, a aplikacja używa innej biblioteki. Czasem kontener zawiera OpenSSL wyłącznie jako narzędzie administracyjne.

Ocena powinna odpowiedzieć na cztery pytania:

który proces przyjmuje niezaufane połączenia TLS;
z jaką biblioteką i wersją jest faktycznie połączony w czasie działania;
czy dostawca przeniósł poprawkę bez zmiany głównego numeru wersji;
jakie limity pamięci, połączeń i timeoutów chronią ten proces.

To ten sam problem widoczności, który opisujemy w przewodniku o SBOM i inwentaryzacji komponentów. Obraz kontenera, host, sidecar i urządzenie sieciowe mogą mieć różne kopie biblioteki. Aktualizacja jednej warstwy nie gwarantuje, że ruch produkcyjny korzysta już z poprawionego kodu.

Plan aktualizacji bez zgadywania

Najpierw utwórz listę wszystkich publicznych i wewnętrznych terminatorów TLS. Uwzględnij CDN, WAF, ingress, reverse proxy, load balancery, serwery aplikacyjne, pocztę, VPN i urządzenia. Dla usług zarządzanych uzyskaj pisemne potwierdzenie dostawcy. Dla własnych obrazów sprawdź pakiety oraz bibliotekę ładowaną przez proces, nie tylko wynik polecenia klienta openssl version.

Następnie przypisz właściciela biznesowego i technicznego. Priorytet powinny dostać usługi dostępne z Internetu, bez skutecznego limitu połączeń, działające w małych kontenerach i współdzielące węzeł z krytycznymi workloadami. Aktualizację testuj najpierw w canary: poprawka dotyka obsługi handshake, więc warto sprawdzić zgodność klientów, mTLS, wznowienia sesji, inspekcję TLS i wydajność.

Po wdrożeniu potwierdź, że nowy artefakt rzeczywiście działa. Porównaj digest obrazu, mapę bibliotek procesu, wersję pakietu i identyfikator buildu. Dopiero obserwacja ruchu oraz stabilności canary daje podstawę do rozszerzenia rollout’u. Szerzej ten proces opisuje audyt TLS 1.3, mTLS i PKI.

Ograniczenia tymczasowe nie zastępują poprawki

Kiedy aktualizacja wymaga okna serwisowego, zespół może skrócić nieaktywne handshake’y, obniżyć limit połączeń z jednego źródła, zastosować globalny connection budget oraz odseparować pule workerów. Reverse proxy przed usługą może pochłaniać część asymetrii, pod warunkiem że sam nie używa podatnego wzorca. Ochrona warstwowa powinna również zapobiegać temu, by jeden kontener wyczerpał pamięć całego węzła.

Żaden pojedynczy limit nie jest pełną poprawką. Źródła mogą być rozproszone, a zbyt agresywny rate limiting odetnie legalnych użytkowników za NAT-em. WAF analizujący HTTP może w ogóle nie zobaczyć problemu, ponieważ ruch zatrzymuje się przed powstaniem żądania HTTP. Mechanizmy znane z analizy ataku HTTP/2 Rapid Reset pomagają w ograniczaniu wolumenu i anomalii połączeń, lecz nie usuwają błędu alokacji.

Jak wykrywać próbę wykorzystania

Nie istnieje jeden niezawodny IOC. Najbardziej przydatna jest korelacja zachowania:

gwałtowny wzrost liczby nieukończonych handshake’ów TLS;
wysoki RSS procesu przy małym wolumenie odebranych danych;
duża liczba sesji oczekujących na kolejne bajty ClientHello;
rosnąca fragmentacja i brak proporcjonalnego spadku RSS po zamknięciu sesji;
restarty workerów, zdarzenia OOMKilled lub błędy alokacji;
wiele krótkich rekordów rozpoczynających handshake bez dalszej transmisji;
równoczesne pogorszenie latencji i dostępności innych usług na tym samym hoście.

Telemetria sieciowa bez metryk procesu może pokazać tylko tysiące małych połączeń. Metryki procesu bez sieci mogą przypominać wyciek pamięci. Połączenie obu perspektyw w SIEM, EDR lub XDR pozwala odróżnić anomalię protokołu od normalnego wzrostu obciążenia.

Nie zalecamy odtwarzania ataku w produkcji. Walidację poprawki należy wykonać w izolowanym laboratorium, z limitem pamięci i obserwacją alokacji, używając testu zaakceptowanego przez właściciela systemu. Publiczny proof of concept nie jest konieczny, by potwierdzić wersję i poprawione zachowanie.

Reagowanie na podejrzany incydent

Jeżeli proces gwałtownie zużywa RAM, najpierw chroń dostępność: odizoluj zagrożoną pulę, skieruj ruch do zdrowych instancji i ogranicz nowe handshake’y. Zachowaj próbki ruchu, metryki połączeń, logi kernela, zdarzenia cgroup, wersję biblioteki i konfigurację timeoutów. Restart może być konieczny operacyjnie, ale powinien nastąpić po zebraniu minimalnego materiału dowodowego.

Następnie ustal, czy był to celowy ruch, błąd klienta, test monitoringu czy niezamierzona burza połączeń. HollowByte nie prowadzi sam w sobie do kradzieży danych; jego potwierdzonym skutkiem jest zużycie zasobów i potencjalna niedostępność. Nie rozszerzaj komunikatu o wykonanie kodu lub przejęcie serwera bez odrębnych dowodów.

Procedura powinna być częścią planu reagowania na incydent: kto przełącza ruch, kto zatwierdza limity, gdzie trafia capture, jak ustala się wersję runtime i kiedy informowani są klienci. Awaria pamięci na brzegu może uruchomić efekt domina, dlatego ćwiczenie scenariusza przed incydentem ma realną wartość.

Co HollowByte mówi o zarządzaniu ryzykiem

Ten przypadek pokazuje lukę między klasycznym skanowaniem CVE a praktyczną odpornością. Istotna poprawka może nie mieć CVE, CVSS ani wpisu w popularnym feedzie. Zespół, który ogranicza patch management do krytycznych numerów z automatycznego skanera, może ją całkowicie ominąć.

Dojrzały proces śledzi projekty upstream, biuletyny dystrybucji i artefakty wdrożone w runtime. Łączy to z testami odporności, budżetami zasobów i bezpiecznym projektowaniem. W przypadku TLS warto podczas testów penetracyjnych aplikacji webowych oceniać nie tylko szyfry i certyfikaty, ale też zachowanie warstwy terminującej połączenie pod presją.

HollowByte nie jest powodem do paniki ani dowodem, że każda aplikacja z OpenSSL jest podatna. Jest powodem do konkretnej weryfikacji: sprawdź bibliotekę, potwierdź backport, zaktualizuj narażone terminatory, monitoruj nieukończone handshake’y i przetestuj limity. To znacznie lepsza obrona niż czekanie na numer CVE.

Źródła i rekomendacja

Podstawą artykułu jest techniczna publikacja Okta Red Team oraz publiczne zmiany OpenSSL: PR 30792, PR 30793 i PR 30794. Wyniki pamięciowe przytoczone wyżej są wynikami laboratorium badaczy, nie uniwersalną prognozą.

Jeżeli nie wiesz, która kopia OpenSSL kończy ruch w Twojej organizacji, potrzebujesz najpierw inwentaryzacji i testu konfiguracji. Skontaktuj się z Breach Road, aby zweryfikować publiczne terminatory TLS, zależności runtime, limity zasobów i bezpieczną ścieżkę aktualizacji.