Wprowadzono nową technikę ataku na implementacje protokołu HTTP/2, która ułatwia przeprowadzanie ataków na podstawie wyczerpywania zasobów serwera. Wykryta luka otrzymała kodową nazwę MadeYouReset i pozwala na przesyłanie dużej liczby żądań do serwera za pomocą manipulacji ramkami sterującymi HTTP/2, omijając ustalone ograniczenia.
Istota problemu polega na tym, że klient może utworzyć bardzo dużą liczbę równocześnie przetwarzanych strumieni, niezależnie od limitu SETTINGS_MAX_CONCURRENT_STREAMS, resetując każdy strumień na wczesnym etapie. Tego rodzaju reset powoduje, że do wysłania nowego żądania w ustalonym połączeniu HTTP/2 klient nie musi czekać na odpowiedź. serwera Może od razu skierować dużą, nieprzerwaną rzędy żądań, w ramach możliwości przepustowości kanału komunikacyjnego.
Klient przestaje być uzależniony od opóźnień między wysłaniem żądania a otrzymaniem odpowiedzi (RTT, round-trip time) i może przeprowadzić atak przy minimalnych kosztach operacyjnych, podczas gdy serwer nadal wydaje zasoby na przetwarzanie nadchodzących żądań. Na przykład, serwer musi alokować struktury danych dla nowych strumieni, analizować żądanie, rozpakować nagłówek i dopasować URL do zasobu. W przypadku ataku na odwrotne serwery proxy, atak może rozprzestrzenić się na backendy, na które proxy zdąży przekazać żądanie przed jego zresetowaniem.
Wrażliwość przypomina wcześniej znaną problematykę Rapid Reset (CVE-2023-44487) i jest spowodowana niezgodnością logiki resetowania strumieni, określonej w specyfikacji protokołu HTTP/2 oraz zaimplementowanej w końcowych produktach. W specyfikacji przewidziano możliwość resetowania strumienia przez klienta i serwer w dowolnym momencie, jednak w wielu implementacjach HTTP/2,serwerów po takim resecie żądanie nadal jest przetwarzane. Kluczową różnicą nowego ataku jest to, że resetowanie przetwarzania żądania ma miejsce z inicjatywy serwera, a nie poprzez wysłanie przez klienta ramki z flagą RST_STREAM.
Reset initiated by the server occurs when invalid requests are received, but such requests are discarded immediately without starting their full processing and without passing to the backend. In order to achieve a complete processing cycle of the request, the attacker can first send a correct HTTP request, followed by an incorrect sequence of control frames in HTTP/2. Such activity will result in the server starting to fully process the request, but then due to an error in processing the subsequent frames, it will drop the stream (changing the stream with the correct request to the RST_STREAM state).
The issue has been confirmed in HTTP servers such as Apache Tomcat, Netty, Eclipse Jetty, Fastly, varnish, lighttpd, and Zephyr RTOS. The problem is also manifested on websites and server services of Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed, and HAProxy are not affected by the issue. The vulnerability status in nginx has not been determined.
Źródło: opennet.ru
