Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Projekt OpenSSL usunął podatność określaną jako HollowByte, która mogła zostać wykorzystana do zdalnego wywołania odmowy usługi poprzez wyczerpanie pamięci procesu obsługującego połączenia TLS. Problem dotyczył bardzo wczesnego etapu handshake’u, jeszcze przed ustanowieniem właściwej sesji szyfrowanej, co czyniło go szczególnie atrakcyjnym dla atakujących.
Najistotniejsze jest to, że scenariusz ataku nie wymagał uwierzytelnienia, poprawnych poświadczeń ani przełamania mechanizmów kryptograficznych. Wystarczało odpowiednio przygotować dane wejściowe, aby wymusić kosztowne operacje po stronie serwera i doprowadzić do degradacji dostępności usługi.
W skrócie
- HollowByte to błąd logiczny w przetwarzaniu nagłówka wiadomości handshake TLS.
- Podatność pozwalała na przedwczesną alokację pamięci na podstawie niezaufanej deklaracji długości.
- Skutkiem mogło być jednoczesne zużycie pamięci i blokowanie wątków roboczych oczekujących na dane, które nigdy nie nadejdą.
- Poprawka zmienia sposób alokacji bufora na przyrostowy, zgodny z faktycznie odebranymi bajtami.
- Ryzyko dotyczy szerokiego ekosystemu usług korzystających z OpenSSL jako warstwy kryptograficznej.
Kontekst / historia
Podatność została opisana przez zespół Red Team firmy Okta jako błąd denial-of-service związany z biblioteką OpenSSL. Nazwa HollowByte odnosi się do minimalnego wejścia, które może uruchomić nieproporcjonalnie kosztowne działania po stronie serwera, tworząc klasyczną asymetrię kosztów między atakującym a ofiarą.
To kolejny przykład problemu, w którym zaufanie do pól sterujących przekazywanych na bardzo wczesnym etapie komunikacji prowadzi do ryzyka operacyjnego. Choć błąd nie umożliwia wykonania kodu ani ujawnienia danych, może istotnie zakłócić działanie usług internetowych opartych na TLS, a więc uderza bezpośrednio w ich dostępność.
Analiza techniczna
Istota błędu polegała na tym, że podatne wersje OpenSSL ufały deklarowanemu przez klienta rozmiarowi wiadomości handshake jeszcze przed pełnym odebraniem danych. W praktyce serwer mógł zarezerwować bufor wyłącznie na podstawie wartości z nagłówka, mimo że rzeczywisty ładunek nie został jeszcze dostarczony.
Ten mechanizm prowadził do dwóch równoległych obciążeń. Po pierwsze, następowała zbyt wczesna i potencjalnie kosztowna alokacja pamięci. Po drugie, wątek roboczy pozostawał zajęty oczekiwaniem na dalsze dane wejściowe, których atakujący nie musiał już wysyłać. W środowiskach z ograniczoną liczbą workerów lub przy wysokim wolumenie nowych połączeń TLS mogło to szybko przełożyć się na spadek wydajności całej usługi.
Dodatkowym problemem pozostaje zachowanie alokatora pamięci. Nawet po zamknięciu podejrzanych połączeń zwolnione bufory nie zawsze wracają natychmiast do systemu operacyjnego, co może powodować utrzymujący się wzrost zużycia pamięci rezydentnej oraz fragmentację sterty. W skrajnych przypadkach pełne odzyskanie zasobów może wymagać restartu procesu lub usługi.
Wprowadzone przez OpenSSL poprawki zmieniają model zarządzania buforem. Zamiast jednorazowo alokować pamięć zgodnie z deklaracją z nagłówka, biblioteka zwiększa bufor stopniowo, proporcjonalnie do rzeczywiście odebranych danych. Dzięki temu fałszywa deklaracja długości nie powoduje już porównywalnego obciążenia pamięci na starcie handshake’u.
Konsekwencje / ryzyko
Najważniejszą konsekwencją HollowByte jest ryzyko odmowy usługi. Objawy mogą obejmować wzrost wykorzystania RAM, blokowanie wątków roboczych, wydłużenie czasów odpowiedzi, spadek przepustowości oraz wymuszone restarty usług wywołane przez mechanizmy ochrony pamięci lub działania administratorów.
Skala problemu jest znacząca, ponieważ OpenSSL stanowi fundament wielu klas oprogramowania, w tym serwerów WWW, reverse proxy, usług API, środowisk uruchomieniowych oraz części systemów bazodanowych. Najbardziej zagrożone są publicznie dostępne punkty końcowe TLS, szczególnie tam, gdzie duża liczba krótkich połączeń jest zjawiskiem normalnym.
Choć podatność nie prowadzi bezpośrednio do naruszenia poufności ani integralności danych, jej wpływ biznesowy może być poważny. Dla organizacji utrzymujących usługi internetowe nawet krótkotrwała niedostępność oznacza ryzyko strat finansowych, naruszenia umów SLA i pogorszenia zaufania klientów.
Rekomendacje
Priorytetem powinno być wdrożenie wersji OpenSSL zawierającej poprawkę. Organizacje powinny sprawdzić nie tylko bibliotekę instalowaną systemowo, ale także komponenty statycznie linkowane, obrazy kontenerów oraz produkty dostawców zewnętrznych, które mogą używać własnej kopii OpenSSL.
Warto przeprowadzić inwentaryzację wszystkich punktów końcowych TLS i wskazać te, które są bezpośrednio dostępne z Internetu. Szczególną uwagę należy poświęcić serwerom WWW, bramom API, load balancerom, usługom pocztowym i aplikacjom zależnym od stosu kryptograficznego OpenSSL.
- Zaktualizować OpenSSL oraz zależne komponenty i obrazy kontenerowe.
- Zweryfikować produkty firm trzecich pod kątem osadzonych kopii biblioteki.
- Monitorować anomalie podczas handshake TLS, wzrost pamięci rezydentnej i nietypowo długo zajęte workery.
- Skonfigurować alerty dla skoków zużycia RAM, częstych restartów i oznak fragmentacji pamięci.
- Uzupełnić poprawkę o timeouty połączeń, limity zasobów, warstwę reverse proxy oraz testy odporności po wdrożeniu zmian.
Mechanizmy takie jak rate limiting czy ograniczanie liczby połączeń nadal mają znaczenie, ale nie powinny być traktowane jako kompletna ochrona. W tym przypadku kluczowe jest usunięcie źródła problemu w samej bibliotece, a dopiero potem wzmacnianie ochrony operacyjnej na poziomie infrastruktury.
Podsumowanie
HollowByte pokazuje, że nawet niewielkie i pozornie niegroźne dane wejściowe mogą uruchomić kosztowne operacje po stronie serwera, jeśli implementacja zbyt wcześnie ufa niezaufanym polom sterującym. To podatność typowo operacyjna, ale jej wpływ na dostępność usług może być bardzo realny.
Z uwagi na powszechność OpenSSL aktualizacja powinna zostać potraktowana jako zadanie wysokiego priorytetu. Najlepszą praktyką będzie połączenie wdrożenia poprawki z przeglądem zależności, monitoringiem zużycia zasobów i walidacją odporności usług wystawionych na ruch TLS z Internetu.