dnsmasq, 6 nuove vulnerabilità gravi: perché aggiornare subito

Dnsmasq resta uno dei componenti più diffusi nei router domestici, nei firewall embedded, nelle distribuzioni Linux e nei sistemi IoT che integrano funzioni di resolver DNS e DHCP leggere. Basta guardare a OpenWrt, ai firmware dei modem consumer oppure a molte appliance industriali per capire quanto sia installato il progetto sviluppato dal maintainer principale Simon Kelley. Proprio per questo l’annuncio pubblicato da Kelley ha subito attirato l’attenzione della comunità sicurezza: 6 nuove vulnerabilità considerate gravi colpiscono praticamente tutte le versioni non obsolete del software.

La comunicazione arriva direttamente dalla mailing list ufficiale del progetto e accompagna il rilascio di dnsmasq 2.92rel2, build che integra le patch correttive già distribuite in anteprima ai vendor. Il dato interessante non riguarda solo le vulnerabilità in sé; Kelley parla apertamente di un’ondata di ricerca offensiva e difensiva alimentata dall’AI, con una quantità enorme di segnalazioni duplicate, crash riproducibili e bug hunting su larga scala. Il tradizionale modello di disclosure coordinata inizia a mostrare limiti concreti quando il numero di vulnerabilità cresce troppo rapidamente.

Dnsmasq esiste dalla fine degli anni ’90 e nasce con un obiettivo preciso: offrire un resolver DNS e un server DHCP compatti, adatti anche a sistemi con poche risorse. Col tempo però il codice ha accumulato funzionalità più complesse, incluse validazione DNSSEC, PXE boot, TFTP, RA IPv6 e gestione avanzata DHCP. Ogni estensione aumenta inevitabilmente la complessità dell’analisi dei pacchetti di rete: proprio lì vengono a galla i problemi più delicati.

6 CVE e patch urgenti per installazioni dnsmasq diffuse ovunque

L’annuncio ufficiale non entra nei dettagli tecnici delle singole vulnerabilità, ma conferma che i bug sono “long-standing“, quindi presenti da tempo nel codice. Tale caratteristica rende il quadro più delicato: una falla rimasta nascosta per anni potrebbe essere già stata studiata da attori ostili senza alcuna evidenza pubblica.

Secondo quanto comunicato da Kelley, le patch sono disponibili sia come backport per la gamma stabile 2.92 sia come modifiche nel ramo di sviluppo che porterà a dnsmasq 2.93.

Una delle vulnerabilità riguarda un problema di gestione di record RRSIG malformati. I record RRSIG fanno parte del meccanismo DNSSEC e servono per autenticare le risposte DNS tramite firme crittografiche. Un parser poco robusto può andare incontro a condizioni di buffer overflow, corruzione memoria oppure crash del processo dnsmasq. In ambienti embedded il rischio non è banale: molti router eseguono dnsmasq come processo dotato di privilegi elevati e un arresto del servizio può interrompere simultaneamente risoluzione DNS e assegnazione DHCP.

La gravità dipende anche dalla configurazione. Sistemi che usano DNSSEC validation, forwarding DNS esterno oppure risposte provenienti da resolver non fidati espongono una superficie d’attacco più ampia. Nei dispositivi consumer il problema si amplia perché molti utenti non aggiornano mai il firmware del router.

Perché dnsmasq è un bersaglio interessante

Dnsmasq gira spesso in ambienti poco monitorati: router domestici, gateway LTE industriali, access point, NAS, hypervisor leggeri e sistemi containerizzati. Molti amministratori lo considerano quasi “trasparente” perché funziona bene per anni senza richiedere interventi. Proprio questa invisibilità operativa lo rende appetibile.

Un attaccante che riesce a provocare un crash remoto del servizio DNS può ottenere diversi effetti pratici: DoS (Denial of Service) locale, degrado della connettività oppure riavvii continui del daemon corrispondente. In alcuni casi, bug legati al parsing DNS possono avere conseguenze gravi come heap corruption o scrittura arbitraria di informazioni in memoria.

Storicamente dnsmasq ha già affrontato incidenti rilevanti: alcuni ricorderanno il pacchetto di vulnerabilità DNSpooq divulgato nel 2021 che combinava problemi di cache poisoning e memory corruption. Quelle falle dimostrarono una cosa importante: software piccoli e apparentemente maturi non sono immuni da bug critici, specialmente quando devono elaborare protocolli complessi e input di rete altamente variabili.

L’effetto dell’AI sulla ricerca delle vulnerabilità

La parte più interessante del messaggio di Kelley riguarda forse il metodo con cui emergono i bug. L’autore parla apertamente di una “rivoluzione” nella ricerca sulla sicurezza informatica basata su AI.

Strumenti di fuzzing assistito da modelli linguistici e analisi automatica del codice riescono oggi a generare test case, individuare percorsi vulnerabili e proporre proof-of-concept di exploit funzionanti con una velocità impensabile pochi anni fa.

Il problema è la quantità di segnalazioni: Kelley racconta di aver passato settimane a eliminare duplicati e classificare i report. Succede perché molti ricercatori usano tool simili sugli stessi repository pubblici. Quando il codice contiene bug relativamente semplici da raggiungere tramite fuzzing, decine di persone possono trovare la stessa anomalia quasi contemporaneamente.

Kelley lascia intendere un cambio di priorità: correggere rapidamente il codice e distribuire release aggiornate invece di prolungare processi di coordinamento troppo pesanti. È una posizione che molti maintainer open source iniziano a condividere, soprattutto nel caso dei progetti gestiti da team piccoli.

Daniel Stenberg, ideatore e principale responsabile del progetto curl ha dovuto chiudere il programma bug bounty per via delle segnalazioni AI mentre più di recente ha pubblicato un suo commento sull’analisi della sua applicazioni (utilizzata su miliardi di dispositivi) da parte di Anthropic Mythos. È emerso che l’AI ha alla fine rilevato soltanto un’unica vulnerabilità, per di più di scarso rilievo.