{"id":114790,"date":"2024-04-04T18:25:42","date_gmt":"2024-04-04T16:25:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/ataka-continuation-flood-privodyashhaya-k-problemam-na-serverah-ispolzuyushhih-http-2-0"},"modified":"2024-04-04T18:25:42","modified_gmt":"2024-04-04T16:25:42","slug":"ataka-continuation-flood-privodyashhaya-k-problemam-na-serverah-ispolzuyushhih-http-2-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/ataka-continuation-flood-privodyashhaya-k-problemam-na-serverah-ispolzuyushhih-http-2-0","title":{"rendered":"Atak typu Continuation flood, prowadz\u0105ca do problem\u00f3w na serwerach korzystaj\u0105cych z HTTP\/2.0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zosta\u0142y ujawnione informacje o metodzie ataku \u201eContinuation flood\u201d, dotykaj\u0105cej r\u00f3\u017cnych implementacji protoko\u0142u HTTP\/2, w tym Apache httpd, Apache Traffic Server, Node.js, oghttp, Go net\/http2, Envoy, oghttp i nghttp2. Luka mo\u017ce by\u0107 wykorzystywana do przeprowadzania atak\u00f3w na serwery obs\u0142uguj\u0105ce HTTP\/2.0, a w zale\u017cno\u015bci od implementacji prowadzi do wyczerpania pami\u0119ci (przerwanie przetwarzania \u017c\u0105da\u0144 lub awaryjne zako\u0144czenie proces\u00f3w) lub generowania du\u017cego obci\u0105\u017cenia CPU (spowolnienie przetwarzania \u017c\u0105da\u0144). Zdaniem badacza, kt\u00f3ry odkry\u0142 t\u0119 luk\u0119, wykryty problem jest bardziej niebezpieczny ni\u017c zesz\u0142oroczna luka \u201eRapid Reset\u201d, kt\u00f3ra by\u0142a wykorzystywana do przeprowadzania najwi\u0119kszych w\u00f3wczas atak\u00f3w DDoS. <\/p>\n

Wysoki poziom zagro\u017cenia wynika z faktu, \u017ce do zak\u0142\u00f3cenia dzia\u0142ania serwera<\/a>, awaryjnego zako\u0144czenia lub powa\u017cnego obni\u017cenia wydajno\u015bci wystarczy stworzenie strumienia specjalnie sformatowanych \u017c\u0105da\u0144 z jednego zwyk\u0142ego komputera. W pewnych przypadkach do przeprowadzenia ataku wystarczy nawet jedno po\u0142\u0105czenie TCP. Przy tym ruch zwi\u0105zany z przeprowadzeniem ataku w \u017caden spos\u00f3b nie wyr\u00f3\u017cnia si\u0119 w logach na tle zwyk\u0142ych \u017c\u0105da\u0144 u\u017cytkownik\u00f3w. <\/p>\n

Luka ta wynika z charakterystyki przetwarzania ramki HEADERS oraz CONTINUATION w \u017c\u0105daniach protoko\u0142u HTTP\/2. Ramki HEADERS s\u0105 u\u017cywane w HTTP\/2 do przesy\u0142ania nag\u0142\u00f3wk\u00f3w HTTP, a ramki CONTINUATION do dzielenia wysy\u0142ania nag\u0142\u00f3wk\u00f3w HTTP na kilka etap\u00f3w (na przyk\u0142ad, gdy nag\u0142\u00f3wki nie mieszcz\u0105 si\u0119 w jednej ramce lub gdy na pocz\u0105tku nale\u017cy wys\u0142a\u0107 nag\u0142\u00f3wki, kt\u00f3re mo\u017cna wype\u0142ni\u0107 na bie\u017c\u0105cym etapie, a nast\u0119pnie do przes\u0142a\u0107 nag\u0142\u00f3wki, kt\u00f3rych warto\u015bci na razie nie mo\u017cna okre\u015bli\u0107). Podczas przesy\u0142ania nag\u0142\u00f3wk\u00f3w w kilku etapach najpierw wysy\u0142ana jest ramka HEADERS bez flagi END_HEADERS, za kt\u00f3r\u0105 pod\u0105\u017ca kilka ramek CONTINUATION z dodatkowymi nag\u0142\u00f3wkami, a list\u0119 zamyka ramka CONTINUATION z flag\u0105 END_HEADERS. <\/p>\n

Metoda ataku polega na wysy\u0142aniu nieprzerwanych strumieni ramek CONTINUATION bez ustalania flagi END_HEADERS. Taka aktywno\u015b\u0107 prowadzi do przesy\u0142ania na serwer<\/a> du\u017cej liczby nag\u0142\u00f3wk\u00f3w, kt\u00f3re serwer przechowuje w pami\u0119ci podr\u0119cznej, dop\u00f3ki dost\u0119pna pami\u0119\u0107 procesu nie zostanie wyczerpana. Aby wygenerowa\u0107 du\u017c\u0105 obci\u0105\u017cenie CPU, opr\u00f3cz wyczerpywania pami\u0119ci, atakuj\u0105cy mo\u017ce wykorzysta\u0107 kompresj\u0119 zawarto\u015bci ramki CONTINUATION za pomoc\u0105 formatu HPACK, kt\u00f3rego analiza wymaga oblicze\u0144. W implementacjach protoko\u0142u HTTP\/1.1 w celu ochrony przed zalaniami serwera nag\u0142\u00f3wkami wprowadzono limit rozmiaru nag\u0142\u00f3wk\u00f3w oraz timeout dla czasu wysy\u0142ania po\u0142\u0105czenia. Dla HTTP\/2, z uwagi na z\u0142o\u017cono\u015b\u0107 protoko\u0142u, wiele realizacji nie przewidzia\u0142o podobnych metod obrony przed nieko\u0144cz\u0105c\u0105 si\u0119 wysy\u0142k\u0105 nag\u0142\u00f3wk\u00f3w. <\/p>\n

Najwi\u0119ksze zagro\u017cenie luka ta stanowi dla u\u017cytkownik\u00f3w Node.js (CVE-2024-27983), poniewa\u017c ta implementacja pozwala na uzyskanie awarii poprzez wys\u0142anie zaledwie kilku ram na serwer. Z powodu stanu wy\u015bcigu w Node.js, aby wywo\u0142a\u0107 awaryjne zako\u0144czenie poprzez aktywacj\u0119 sprawdzenia Assert, wystarczy zako\u0144czy\u0107 po\u0142\u0105czenia podczas wysy\u0142ania niekompletnego strumienia nag\u0142\u00f3wk\u00f3w (awaria, je\u015bli w trakcie zamykania po\u0142\u0105cze\u0144 jeszcze nie nadesz\u0142a ramka CONTINUATION z flag\u0105 END_HEADERS). Luka zosta\u0142a usuni\u0119ta w Node.js 18.20.1, 21.7.2 i 20.12.1, a tak\u017ce w najnowszych wersjach bibliotek llhttp i undici. W nowych wersjach Node.js usuni\u0119to r\u00f3wnie\u017c mniej niebezpieczn\u0105 luk\u0119 (CVE-2024-27982) klasy \u201erequest smuggling\u201d, kt\u00f3ra pozwala na w\u0142\u0105czenie si\u0119 w zawarto\u015b\u0107 \u017c\u0105da\u0144 innych u\u017cytkownik\u00f3w poprzez manipulacj\u0119 warto\u015bci\u0105 \u201eContent Length\u201d obs\u0142ugiwanych w tym samym w\u0105tku mi\u0119dzy frontendem a backendem. <\/p>\n

Luki zwi\u0105zane z obs\u0142ug\u0105 CONTINUATION w innych implementacjach HTTP\/2.0: <\/p>\n