È stata presentata una nuova tecnica di attacco alle implementazioni del protocollo HTTP/2, che semplifica la conduzione di attacchi per provocare un'interruzione del servizio tramite il consumo delle risorse del server. La vulnerabilità è stata soprannominata MadeYouReset e consente, attraverso la manipolazione dei frame di controllo HTTP/2, di inondare il server con un gran numero di richieste, eludendo i vincoli impostati.
Il problema principale è che il cliente può creare un numero molto elevato di flussi elaborati simultaneamente, indipendentemente dal limite SETTINGS_MAX_CONCURRENT_STREAMS, resettando ogni flusso all'inizio. Questo reset fa sì che per inviare una nuova richiesta nella connessione stabilita HTTP/2 non sia necessario attendere una risposta da server e si può immediatamente inviare un grande flusso continuo di richieste, fino al limite della capacità di banda disponibile.
Il cliente smette di dipendere dai ritardi tra l'invio della richiesta e la ricezione della risposta (RTT, round-trip time) e può condurre un attacco con costi marginali, mentre il server continua a spendere risorse per elaborare le richieste in arrivo. Ad esempio, il server effettua l'allocazione delle strutture dati per i nuovi flussi, l'analisi della richiesta, la decompressione dell'intestazione e il confronto dell'URL con la risorsa. In un attacco ai proxy reversi, l'attacco può espandersi ai backend verso i quali il proxy riesce a reindirizzare la richiesta prima del suo reset.
La vulnerabilità ricorda un problema già noto come Rapid Reset (CVE-2023-44487) ed è causata da una divergenza nella logica di reset dei flussi, definita nella specifica del protocollo HTTP/2 e implementata nei prodotti finali. Nella specifica è prevista la possibilità di resettare il flusso dal client e dal server in qualsiasi momento, ma in molte implementazioni HTTP/2,server dopo tale reset la richiesta continua a essere elaborata. La principale differenza del nuovo attacco è che il reset dell'elaborazione della richiesta avviene su iniziativa del server e non tramite l'invio da parte del client di un frame con il flag RST_STREAM.
Il riavvio per iniziativa del server avviene quando vengono ricevute richieste non valide, ma tali richieste vengono scartate immediatamente senza avviare un'elaborazione completa e senza essere trasmesse al backend. Per completare il ciclo di elaborazione della richiesta, l'attaccante potrebbe iniziare inviando una richiesta HTTP valida, seguita da una sequenza non valida di frame di controllo HTTP/2. Tale attività porterà il server a iniziare a elaborare la richiesta, ma a causa di un errore nell'elaborazione dei frame successivi, il flusso verrà resettato (portando il flusso con la richiesta valida allo stato RST_STREAM).
La presenza del problema è stata confermata nei server HTTP Apache Tomcat, Netty, Eclipse Jetty, Fastly, varnish, lighttpd, 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 vulnerabili al problema. Lo stato della vulnerabilità in nginx non è stato determinato.
Fonte: opennet.ru
