A fost prezentată o nouă tehnică de atac asupra implementărilor protocolului HTTP/2, care simplifică efectuarea atacurilor de tip denial-of-service prin epuizarea resurselor serverului. Vulnerabilitatea a primit numele de cod MadeYouReset și permite, prin manipularea cadrelor de control HTTP/2, inundarea serverului cu un număr mare de cereri, ocolind limitele stabilite.
Esentialul problemei este că un client poate crea un număr foarte mare de fluxuri procesate simultan, indiferent de limita SETTINGS_MAX_CONCURRENT_STREAMS, resetând fiecare flux la început. O astfel de resetare face ca pentru a trimite o nouă cerere în conexiunea HTTP/2 stabilită, clientul să nu fie necesar să aștepte răspunsul de la server și poate direcționa imediat un mare flux continuu de cereri, cât permite lățimea de bandă a canalului de comunicație.
Clientul încetează să depindă de întârzierile dintre trimiterea cererii și primirea răspunsului (RTT, round-trip time) și poate lansa un atac cu costuri minime, pe când serverul continuă să cheltuie resurse pentru procesarea cererilor primite. De exemplu, serverul alocă structuri de date pentru noi fluxuri, analizează cererea, decompune antetul și potrivi URL-ul cu resursa. În cazul unui atac asupra proxy-urilor inverse, atacul se poate extinde la backend-urile către care proxy-ul reușește să redirecționeze cererea înainte de resetare.
Vulnerabilitatea este similară cu problema cunoscută anterior, Rapid Reset (CVE-2023-44487) și este cauzată de discrepanța între logica resettării fluxurilor, definită în specificația protocolului HTTP/2 și implementată în produsele finale. În specificație este prevăzută posibilitatea resetării fluxului de către client și server în orice moment, dar în multe implementări HTTP/2,servere după o astfel de resetare, cererea continuă să fie procesată. Principalul aspect care distinge noul atac este că resetarea procesării cererii se realizează la inițiativa serverului, și nu prin trimiterea de către client a unui cadru cu flag-ul RST_STREAM.
Resetting by the server's initiative occurs when incorrect requests are received, but such requests are discarded immediately without initiating their full processing and without passing them to the backend. In order to achieve a complete request processing cycle, the attacker may first send a correct HTTP request, but then follow it up with an incorrect sequence of control frames in HTTP/2. Such activity will cause the server to start processing the request properly, but then, due to an error in processing the following frames, it will reset the stream (change the stream state with the correct request to RST_STREAM).
The presence of the problem has been confirmed in HTTP servers like Apache Tomcat, Netty, Eclipse Jetty, Fastly, Varnish, Lighttpd, and Zephyr RTOS. The issue also manifests on websites and server services operated by Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed, and HAProxy are not vulnerable to this problem. The vulnerability status in Nginx remains undetermined.
Sursa: opennet.ro
