È stata presentata una nuova tecnica di attacco alle implementazioni del protocollo HTTP/2, che semplifica l'esecuzione di attacchi di denial of service attraverso l'esaurimento delle risorse del server. La vulnerabilità ha ricevuto il nome in codice MadeYouReset e consente, tramite manipolazioni dei frame di controllo HTTP/2, di inondare il server con un numero elevato di richieste bypassando i vincoli impostati.
Il problema principale è che il client può creare un numero molto elevato di stream elaborati contemporaneamente, indipendentemente dal limite SETTINGS_MAX_CONCURRENT_STREAMS, resettando ogni stream nelle fasi iniziali. Un tale reset si traduce nel fatto che, per inviare una nuova richiesta nella connessione HTTP/2 stabilita, il client non è tenuto ad attendere una risposta da server e può immediatamente inviare un grande flusso continuo di richieste, per quanto consentito dalla larghezza di banda della connessione.
Il client smette di dipendere dai ritardi tra l'invio della richiesta e il ricevimento della risposta (RTT, round-trip time) e può effettuare l'attacco con costi minimi, mentre il server continua a utilizzare risorse per elaborare le richieste in arrivo. Ad esempio, il server deve allocare strutture dati per i nuovi stream, analizzare la richiesta, decomprimere l'intestazione e mappare l'URL con le risorse. In caso di attacco a proxy inversi, l'attacco può propagarsi verso i backend a cui il proxy riesce a reindirizzare la richiesta prima del suo reset.
La vulnerabilità ricorda un problema noto in precedenza, Rapid Reset (CVE-2023-44487), ed è causata da discrepanze nella logica di reset degli stream definita nella specifica del protocollo HTTP/2 e quella attuata nei prodotti finali. Nella specifica è prevista la possibilità di reset da parte del client e del server in qualsiasi momento, ma in molte implementazioni di HTTP/2,server dopo tale reset, la richiesta continua a essere elaborata. La principale distinzione del nuovo attacco è che il reset dell'elaborazione della richiesta avviene su iniziativa del server, piuttosto che tramite l'invio da parte del client di un frame con il flag RST_STREAM.
Il ripristino su iniziativa del server avviene quando si ricevono richieste non valide, ma tali richieste vengono scartate immediatamente senza nessun inizio di elaborazione completa e senza essere inviate al backend. Per completare il ciclo di elaborazione della richiesta, l'attaccante può inizialmente inviare una richiesta HTTP valida, seguita da una sequenza non valida di frame di controllo HTTP/2. Tale attività porterà il server a elaborare completamente la richiesta, ma poi, a causa di un errore nella gestione dei frame successivi, resetterà il flusso (portando il flusso con la richiesta valida nello stato RST_STREAM).
Il problema è stato confermato nei server HTTP Apache Tomcat, Netty, Eclipse Jetty, Fastly, Varnish, Lighttpd e Zephyr RTOS. Il problema si manifesta anche sui siti e servizi server di Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed e HAProxy non sono affetti dal problema. Non è stata definita la presenza di vulnerabilità in Nginx.
Fonte: opennet.ru
