Co naprawdę robi 260 bajtów

Luka, ujawniona 8 lipca przez badacza FoxIO Sebastiena Fery i nazwana XRING, tkwi w QPACK, schemacie kompresji nagłówków, na którym opiera się HTTP/3. Żadna z wartości w ataku nie łamie reguł QPACK. XQUIC domyślnie ogłasza limit tabeli dynamicznej 16 KiB; ładunek prosi o 64 bajty, potem 65, i wpycha tabelę w dokładnie ten zawinięty układ pamięci, który trafia w wadliwą gałąź. Proces serwera pada. Bez danych logowania, bez zbyt dużych pakietów, bez niczego, co zapora oznaczy jako zniekształcone.

Właśnie to czyni ją niebezpieczną. Większość filtrowania przeciw blokadzie usług szuka objętości albo wyraźnie złych danych, a XRING nie jest ani jednym, ani drugim. To małe, poprawnie zbudowane żądanie, które zwykły klient mógłby wysłać przez przypadek, i wyrządza szkodę w ścieżce analizy, zanim uruchomi się jakakolwiek logika aplikacji. Każda wersja XQUIC do v1.9.4 włącznie, tej bieżącej, jest podatna, i nie ma poprawionej wersji, na którą można przejść.

Dlaczego możesz go uruchamiać, nie wiedząc o tym

XQUIC to otwarta biblioteka QUIC i HTTP/3 firmy Alibaba, więc ryzyko nie dotyczy tylko Alibaby. Jest osadzona w Tengine, opartym na Nginx serwerze WWW koncernu, który według FoxIO obsługuje chmurę i sieć dostarczania treści Alibaby na usługach takich jak Taobao i Alipay. Każdy operator, który wciągnął XQUIC do własnego środowiska, albo uruchamia produkt dostarczający tę bibliotekę wyżej, dziedziczy tę samą słabość, niezależnie od tego, czy zna tę zależność.

To niewygodna część dla każdego, kto prowadzi nowoczesną infrastrukturę WWW. HTTP/3 rozrosło się po cichu przez sieci CDN i rozdzielacze obciążenia, a biblioteki pod spodem są współdzielone. Luka w szeroko osadzonej implementacji QUIC nie jest problemem jednego dostawcy, lecz narażeniem łańcucha dostaw, które wychodzi wszędzie tam, gdzie ten kod ponownie wykorzystano. Zależność, której nie umiesz nazwać, to ta, której nie umiesz załatać.

Poprawka to linia konfiguracji, a żadne CVE cię nie ostrzeże

Dopóki nie ukaże się poprawiona wersja, środek zaradczy jest operacyjny, a nie do pobrania. Możesz ustawić SETTINGS_QPACK_MAX_TABLE_CAPACITY na 0, co wyłącza dynamiczną tabelę QPACK i usuwa podatną ścieżkę, albo możesz zrezygnować z obsługi HTTP/3 i wrócić do HTTP/2, dopóki poprawka jest przygotowywana. Oba to zmiany, które operator wprowadza dziś we własnej konfiguracji, a nie czekanie na cykl łatek dostawcy.

Szersza lekcja dotyczy tego, jak ostrzeżenie dociera, albo nie dociera. Na 10 lipca nie ma CVE dla XRING, więc każdy zespół, który śledzi tylko kanały CVE albo czeka na biuletyn wtorku poprawek, nie zobaczy nic. Rozsądny ruch to zinwentaryzować, gdzie HTTP/3 i QPACK naprawdę działają w twoim środowisku, potwierdzić, która biblioteka QUIC leży pod spodem, i traktować brak CVE jako powód do działania, a nie do rozluźnienia.