In questo articolo Indice dei contenuti 2 sezioni
Una sola richiesta inviata tramite HTTP/3 può arrivare a gonfiare la memoria occupata da un server fino a circa 4.000 volte rispetto ai dati realmente trasmessi. Si tratta di una nuova classe di vulnerabilità che sfrutta il modo in cui il protocollo gestisce le intestazioni delle richieste, descritta dalla ricerca di FoxIO intitolata Header Accordions. Al centro del problema c’è QPACK, il meccanismo di compressione su cui HTTP/3 fa affidamento, insieme a un fenomeno di amplificazione della memoria che può mettere in seria difficoltà le infrastrutture web.
Il rischio riguarda le implementazioni in cui i controlli sulle intestazioni decodificate mancano del tutto, sono incompleti oppure arrivano troppo tardi. In queste condizioni un aggressore remoto riesce a provocare un consumo anomalo di risorse senza nemmeno doversi autenticare. La conseguenza principale è la negazione del servizio, con applicazioni e siti che smettono di rispondere. La scoperta mostra quanto la gestione della memoria pesi sulla tenuta dei servizi esposti a Internet.
Come funziona l’attacco che sfrutta QPACK
Per capire il meccanismo bisogna partire da come è costruito HTTP/3. Il trasporto dei dati è affidato a QUIC mentre QPACK si occupa di ridurre le dimensioni delle intestazioni HTTP. In pratica la compressione sostituisce le informazioni ripetute con riferimenti più corti e così client e server si scambiano meno traffico.
Il guaio nasce quando un’implementazione guarda soltanto a quanto pesano i dati compressi in arrivo e non fissa un limite cumulativo adeguato a ciò che esce dalla decodifica. Il sistema finisce allora per ricostruire numerosi campi e per tenere in memoria una mole di informazioni del tutto sproporzionata rispetto alla richiesta di partenza. È qui che l’amplificazione della memoria prende forma.
Nei test condotti da FoxIO sette implementazioni su dieci hanno mostrato comportamenti vulnerabili. In alcuni casi l’amplificazione ha toccato circa 4.000 volte la quantità di dati inviati, stando alle misurazioni dei ricercatori. Uno squilibrio del genere può prosciugare la memoria disponibile e interrompere l’elaborazione delle richieste legittime.
La ricerca descrive poi uno scenario diverso in cui un errore nella gestione dei contatori è in grado di bloccare il processore. Non si parla necessariamente di accesso a dati riservati o di esecuzione di codice arbitrario perché il pericolo documentato riguarda soprattutto la disponibilità dell’infrastruttura. I risultati indicano che la compressione, se accompagnata da controlli insufficienti, può trasformarsi in una superficie d’attacco tutt’altro che trascurabile per chi gestisce servizi basati su QPACK.
Software coinvolti e contromisure da adottare
Diversi componenti hanno già ricevuto correzioni. Tra questi figurano la libreria QUIC per il linguaggio Go, Cloudflare quiche, lsquic e Wireshark, con versioni correttive indicate rispettivamente nella 0.57.0, nella 0.29.3, nella 4.9.0 e nella 4.6.2 oppure 4.4.12. Gli amministratori di sistema devono verificare quali componenti girano davvero nella propria infrastruttura, dato che una libreria esposta a questa vulnerabilità può essere integrata dentro prodotti più ampi.
Al momento della divulgazione FoxIO segnalava anche alcune implementazioni ancora prive di correzione, tra cui Bun, la libreria Rust h3 e aioquic, quest’ultima utilizzata anche da mitmproxy. Per questi ambienti le indicazioni prevedono di limitare l’esposizione di HTTP/3, disattivare il protocollo in mitmproxy e configurare limiti appropriati alle intestazioni per h3. La disponibilità delle patch può però cambiare, quindi è opportuno consultare gli avvisi ufficiali dei singoli progetti prima di intervenire sulle configurazioni.
Al momento della pubblicazione la ricerca Header Accordions non riportava prove di sfruttamento di questi attacchi nel mondo reale. Esiste però codice dimostrativo già disponibile ed è proprio questo a rendere importante una valutazione tempestiva dell’esposizione.
Fonte: TecnoAndroid