Nowe luki QPACK w HTTP/3 umożliwiają zdalne awarie serwerów i skrajną amplifikację pamięci

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili nową klasę podatności w implementacjach HTTP/3 powiązanych z mechanizmem QPACK, odpowiedzialnym za kompresję nagłówków HTTP w środowisku opartym o QUIC. Problem dotyczy błędnej kontroli rozmiaru nagłówków po dekompresji, co może prowadzić do nadmiernej alokacji pamięci, awarii procesu oraz skutecznych ataków denial-of-service.

W praktyce oznacza to, że niewielki blok skompresowanych danych może po stronie serwera zostać rozwinięty do znacznie większej struktury w pamięci. Jeżeli implementacja nie egzekwuje limitów w odpowiednim momencie, atakujący jest w stanie zdalnie wywołać niestabilność usługi bez potrzeby uwierzytelnienia.

W skrócie

Nowe luki dotyczą wielu implementacji HTTP/3 wykorzystujących QPACK.
Atak może zostać przeprowadzony zdalnie i bez uwierzytelnienia, nawet przy użyciu pojedynczego połączenia.
W części scenariuszy możliwa jest bardzo wysoka amplifikacja zużycia pamięci, sięgająca około 4000:1.
Skutkiem może być awaria serwera, wyczerpanie pamięci lub trwała degradacja wydajności.
Poprawki opublikowano między innymi dla quic-go, Cloudflare quiche, lsquic i Wireshark, ale nie wszystkie projekty były w pełni załatane w momencie ujawnienia problemu.

Kontekst / historia

HTTP/3 został zaprojektowany z myślą o poprawie wydajności komunikacji sieciowej dzięki wykorzystaniu QUIC oraz nowoczesnej kompresji nagłówków. QPACK ogranicza narzut transmisji, ponieważ pozwala reprezentować powtarzające się pola nagłówków za pomocą krótkich odwołań zamiast pełnych ciągów tekstowych.

Źródłem obecnych problemów nie jest jednak sama idea kompresji, lecz sposób jej implementacji. Badania pokazały, że różne biblioteki i stosy sieciowe odmiennie interpretują lub egzekwują limity rozmiaru zdekodowanej listy pól. Część projektów kontroluje jedynie rozmiar danych przesyłanych w sieci, część waliduje je dopiero po pełnej dekompresji, a niektóre nie uwzględniają wszystkich elementów wymaganych przez specyfikację.

To właśnie ta niespójność sprawia, że mechanizmy bezpieczeństwa mogą być pozorne. Atakujący, dysponując relatywnie małym ładunkiem wejściowym, może wymusić po stronie serwera wielokrotnie większy koszt przetwarzania i alokacji zasobów.

Analiza techniczna

Istotą podatności jest rozbieżność pomiędzy rozmiarem skompresowanego bloku nagłówków a realnym kosztem jego odtworzenia w pamięci procesu. Podatny serwer akceptuje mały blok HEADERS, który po dekompresji generuje bardzo dużą liczbę pól nagłówkowych albo wielokrotnie materializuje te same wpisy z dynamicznej tabeli QPACK.

Opisano co najmniej dwa praktyczne scenariusze ataku. Pierwszy polega na upakowaniu ogromnej liczby krótkich i unikalnych nagłówków w jednym bloku. Po stronie odbiorcy prowadzi to do utworzenia setek tysięcy wpisów w strukturach przetwarzających żądanie. Drugi wariant wykorzystuje dynamiczną tabelę QPACK: atakujący zapisuje duży wpis, a następnie odwołuje się do niego tysiące razy za pomocą bardzo krótkich referencji. Każde odwołanie może wymuszać kolejne alokacje i kopiowanie danych, co gwałtownie zwiększa zużycie pamięci.

W analizowanych implementacjach problem wynikał między innymi z braku limitu dla rozmiaru zdekodowanych nagłówków, stosowania limitów dopiero po zakończeniu dekompresji, nieuwzględniania narzutu per pole wymaganego przez specyfikację oraz pozostawiania nieograniczonych wartości domyślnych. W zależności od projektu skutkiem może być wyczerpanie RAM, restart procesu, przeciążenie CPU albo awaria narzędzia analizującego ruch.

Szczególnie istotne jest to, że podatność dotyczy warstwy bazowej, na której opiera się szerszy ekosystem serwerów, proxy, frameworków i narzędzi diagnostycznych. W konsekwencji ryzyko nie ogranicza się do pojedynczej aplikacji, lecz może obejmować większą część infrastruktury usługowej.

Konsekwencje / ryzyko

Najbardziej prawdopodobnym skutkiem jest odmowa usługi. Atakujący nie potrzebuje dużego wolumenu ruchu ani rozbudowanego łańcucha exploitów. Odpowiednio przygotowane żądanie lub niewielka liczba połączeń może wystarczyć do doprowadzenia do niestabilności procesu, zużycia limitów pamięci kontenera albo długotrwałego zablokowania obsługi kolejnych zapytań.

Nie ma obecnie przesłanek, że opisana klasa błędów bezpośrednio umożliwia wykonanie kodu lub wyciek danych. Nie zmniejsza to jednak wagi problemu z perspektywy operacyjnej. Organizacje korzystające z HTTP/3 mogą doświadczyć przerw w dostępności aplikacji, degradacji usług brzegowych, wzrostu kosztów infrastruktury oraz niekontrolowanego skalowania zasobów pod wpływem złośliwego ruchu.

Dodatkowe zagrożenie wynika z zależności pośrednich. Wiele zespołów nie wdraża HTTP/3 samodzielnie, lecz używa produktów, które osadzają podatne biblioteki jako komponent wewnętrzny. Bez pełnej inwentaryzacji stosu technologicznego organizacja może nie wiedzieć, że jej usługi pozostają narażone.

Rekomendacje

W pierwszej kolejności należy ustalić, czy środowisko produkcyjne wykorzystuje biblioteki lub produkty bazujące na podatnych implementacjach HTTP/3. Dotyczy to zarówno serwerów publicznych, jak i reverse proxy, edge proxy, narzędzi deweloperskich oraz komponentów służących do przechwytywania i analizy ruchu.

Kolejnym krokiem powinno być jak najszybsze wdrożenie dostępnych poprawek bezpieczeństwa oraz wersji naprawczych dostawców. Jeżeli aktualizacja nie jest jeszcze dostępna, rozsądnym działaniem tymczasowym będzie wyłączenie HTTP/3 albo ograniczenie jego ekspozycji do zaufanych segmentów sieci.

monitorowanie nagłych wzrostów zużycia pamięci i CPU przez procesy obsługujące HTTP/3,
włączenie alertów dla nietypowych wzorców ruchu QUIC i UDP,
stosowanie limitów zasobów dla kontenerów i procesów brzegowych,
weryfikacja, czy WAF, load balancer lub CDN faktycznie terminują połączenia HTTP/3 przed przekazaniem ruchu dalej,
testowanie odporności usług wystawiających QUIC i HTTP/3,
przegląd konfiguracji QPACK i MAX_FIELD_SECTION_SIZE oraz sprawdzenie, czy limity są egzekwowane inkrementalnie podczas dekodowania.

Warto również skontrolować zależności pośrednie używane przez frameworki webowe i komponenty sieciowe. W wielu przypadkach to właśnie starsza biblioteka osadzona wewnątrz produktu może stanowić realny punkt podatności.

Podsumowanie

Nowe luki związane z QPACK pokazują, że mechanizmy optymalizujące wydajność nowoczesnych protokołów mogą stać się źródłem poważnych problemów z dostępnością usług. W tym przypadku niewielki pakiet danych może wywołać bardzo duże obciążenie pamięci i zasobów serwera, co czyni atak prostym, tanim i praktycznym.

Dla zespołów bezpieczeństwa kluczowe pozostają trzy działania: identyfikacja zależności od podatnych implementacji HTTP/3, szybkie wdrożenie poprawek lub obejść tymczasowych oraz monitorowanie infrastruktury pod kątem anomalii w ruchu QUIC. Wraz ze wzrostem adopcji HTTP/3 znaczenie podobnych błędów będzie rosło również po stronie ryzyka operacyjnego.