HTTP/2 Bomb: nowy wektor DoS błyskawicznie wyczerpujący pamięć serwerów HTTP/2 - Security Bez Tabu

HTTP/2 Bomb: nowy wektor DoS błyskawicznie wyczerpujący pamięć serwerów HTTP/2

Cybersecurity news

Wprowadzenie do problemu / definicja

HTTP/2 Bomb to nowo opisana technika ataku typu denial of service, która wykorzystuje sposób działania protokołu HTTP/2 do gwałtownego zużycia pamięci operacyjnej po stronie serwera. Mechanizm łączy kompresję nagłówków HPACK z kontrolą przepływu HTTP/2, dzięki czemu niewielki ruch generowany przez atakującego może prowadzić do nieproporcjonalnie dużych alokacji pamięci i utrzymywania ich przez dłuższy czas.

W praktyce oznacza to możliwość doprowadzenia do niedostępności aplikacji webowych, API i usług pośredniczących nawet przy użyciu ograniczonych zasobów po stronie napastnika. To sprawia, że HTTP/2 Bomb jest szczególnie niebezpieczny dla organizacji, które bezpośrednio wystawiają usługi HTTP/2 do Internetu.

W skrócie

  • HTTP/2 Bomb wykorzystuje kompresję HPACK i mechanizm flow control do wyczerpywania pamięci RAM serwera.
  • Atak może skutecznie uderzać w domyślne konfiguracje popularnych serwerów, takich jak NGINX, Apache HTTP Server, Microsoft IIS, Envoy i Pingora.
  • Kluczową cechą jest bardzo wysoki współczynnik amplifikacji pamięci, czyli wielokrotnie większe zużycie zasobów po stronie ofiary niż ilość danych wysłanych przez klienta.
  • W testach badaczy wyczerpanie dziesiątek gigabajtów RAM było możliwe w czasie liczonym w sekundach.
  • Dla części platform opublikowano poprawki, ale nie wszystkie środowiska są już zabezpieczone.

Kontekst / historia

Ataki DoS wymierzone w HTTP/2 nie są nowym zjawiskiem. Od lat badacze bezpieczeństwa wskazują, że złożoność tego protokołu, obejmująca wielostrumieniowość, kompresję nagłówków i zaawansowane zarządzanie transmisją, może być nadużywana do przeciążania serwerów.

HTTP/2 Bomb nie bazuje na pojedynczym, całkowicie nowym błędzie implementacyjnym. Jego skuteczność wynika raczej z połączenia dwóch wcześniej znanych klas problemów. Z jednej strony atakujący zmusza serwer do kosztownych operacji pamięciowych związanych z obsługą nagłówków, a z drugiej blokuje szybkie zwalnianie zaalokowanych zasobów. Taka kompozycja sprawia, że tradycyjne limity rozmiaru nagłówków mogą okazać się niewystarczające.

Analiza techniczna

Pierwszy etap ataku wykorzystuje HPACK, czyli mechanizm kompresji nagłówków stosowany w HTTP/2. Napastnik dodaje wpis do dynamicznej tabeli HPACK, a następnie wielokrotnie odwołuje się do niego za pomocą bardzo krótkich reprezentacji indeksowych. Efekt jest taki, że pojedyncze bajty przesyłane przez klienta powodują znacznie większy narzut pamięciowy po stronie serwera.

Drugi etap opiera się na manipulacji kontrolą przepływu. Poprzez ustawienie zerowego okna flow control atakujący utrudnia zakończenie transmisji odpowiedzi i uniemożliwia szybkie zwolnienie zasobów. Serwer utrzymuje stan połączenia, bufory oraz struktury związane z obsługą żądania, co prowadzi do kumulacji pamięci zajętej przez wiele nieukończonych operacji.

Według opublikowanych testów szczególnie podatne okazały się Envoy i Apache httpd, gdzie współczynnik amplifikacji pamięci był bardzo wysoki. W niektórych scenariuszach wyczerpanie 32 GB RAM zajmowało około 10 sekund dla Envoy oraz około 18 sekund dla Apache httpd. Dla NGINX podobny efekt uzyskiwano w około 45 sekund, a w przypadku Microsoft IIS wyczerpanie 64 GB pamięci również było możliwe w czasie krótszym niż minuta.

Istotne jest to, że problem nie wynika wyłącznie z dużego rozmiaru samych nagłówków. Źródłem ryzyka jest przede wszystkim sposób ich wewnętrznej obsługi oraz utrzymywanie zaalokowanych struktur przez mechanizmy protokołu. Dlatego zabezpieczenia koncentrujące się jedynie na limicie zdekodowanych nagłówków mogą nie zapewniać pełnej ochrony.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją HTTP/2 Bomb jest szybka utrata dostępności usług. Dotyczy to nie tylko stron internetowych, ale również interfejsów API, paneli administracyjnych, bram aplikacyjnych i komponentów reverse proxy. W środowiskach produkcyjnych może to oznaczać realne przerwy w działaniu usług, degradację wydajności oraz wzrost kosztów infrastrukturalnych.

Z perspektywy obrony szczególnie zagrożone są organizacje korzystające z domyślnych konfiguracji serwerów HTTP/2, bez twardych limitów liczby nagłówków, bez dodatkowej warstwy filtrującej lub bez mechanizmów ochrony przed nadużyciami protokołu. Ponieważ atak może zostać przeprowadzony relatywnie niskim kosztem, zwiększa to jego atrakcyjność operacyjną dla napastników.

Nie wszystkie środowiska są jednakowo podatne. Częściową ochronę mogą zapewniać sieci CDN, reverse proxy, zapory aplikacyjne oraz własne polityki limitów protokołu. Dla wybranych komponentów opublikowano również poprawki. W NGINX problem został zaadresowany przez dodanie dyrektywy max_headers w wersji 1.29.8, natomiast w Apache httpd mod_http2 2.0.41 podatność otrzymała identyfikator CVE-2026-49975. W opisywanym momencie dla IIS, Envoy i Pingora brakowało jeszcze pełnych poprawek.

Rekomendacje

Organizacje korzystające z HTTP/2 powinny rozpocząć od identyfikacji wszystkich publicznie dostępnych usług, które bezpośrednio terminują połączenia HTTP/2. Następnym krokiem powinna być weryfikacja wersji oprogramowania, dostępnych aktualizacji oraz konfiguracji limitów bezpieczeństwa.

  • Zaktualizować NGINX i Apache do wersji zawierających poprawki.
  • Wymusić limity liczby nagłówków i innych parametrów związanych z obsługą żądań HTTP/2.
  • Rozważyć terminację ruchu HTTP/2 na warstwie reverse proxy, load balancera lub CDN.
  • Wdrożyć reguły WAF i mechanizmy ochrony przed DoS analizujące anomalie w ruchu aplikacyjnym.
  • Monitorować zużycie pamięci, liczbę aktywnych strumieni HTTP/2 oraz nietypowe stany flow control.
  • Przygotować procedury awaryjne obejmujące czasowe ograniczenie lub wyłączenie HTTP/2 tam, gdzie jest to operacyjnie możliwe.

W środowiskach, dla których nie ma jeszcze dostępnych poprawek, uzasadnione jest ograniczenie ekspozycji poprzez zastosowanie dodatkowej warstwy ochronnej wymuszającej restrykcyjne limity protokołu. Warto także przeprowadzić testy odporności w kontrolowanych warunkach, aby potwierdzić skuteczność konfiguracji ochronnych przed pojawieniem się realnych prób nadużyć.

Podsumowanie

HTTP/2 Bomb pokazuje, że połączenie znanych wcześniej mechanizmów może stworzyć wyjątkowo skuteczny wektor ataku DoS. Najgroźniejszą cechą tej techniki jest możliwość osiągnięcia bardzo dużego efektu przy relatywnie niewielkim nakładzie po stronie atakującego.

Dla administratorów i zespołów bezpieczeństwa to wyraźny sygnał, że ekspozycja HTTP/2 powinna zostać pilnie zweryfikowana. Aktualizacje, zaostrzenie limitów oraz wdrożenie dodatkowych warstw ochrony mogą istotnie zmniejszyć ryzyko niedostępności usług wynikającej z tego nowego wariantu ataku.

Źródła