Nelle librerie standard C uClibc e uClibc-ng, usate in molti dispositivi embedded e portatili, è stata identificata una vulnerabilità (CVE non assegnato) che consente di inserire dati fasulli nella cache DNS, utilizzabile per alterare l'indirizzo IP di un dominio arbitrario e reindirizzare le richieste al dominio su un server controllato dall'attaccante.
Il problema colpisce vari firmware Linux per router, punti di accesso e dispositivi IoT, oltre a distribuzioni Linux per sistemi embedded, come OpenWRT e Embedded Gentoo. Si segnala che la vulnerabilità si manifesta in dispositivi di molti produttori (ad esempio, uClibc è usato nei firmware Linksys, Netgear e Axis), ma poiché la vulnerabilità in uClibc e uClibc-ng rimane non corretta, le informazioni dettagliate sui dispositivi e i produttori specifici che presentano il problema non sono ancora divulgate.
La vulnerabilità è causata dall'uso di identificatori di transazione prevedibili nel codice per l'invio di richieste DNS. Il numero identificativo della richiesta DNS veniva scelto incrementando semplicemente un contatore senza applicare ulteriore randomizzazione dei numeri di porta. Questo permetteva di ottenere un avvelenamento della cache DNS tramite l'invio anticipato di pacchetti UDP con risposte fasulle (la risposta viene accettata se arriva prima della risposta reale server e include un ID corretto). A differenza del metodo di Kaminsky proposto nel 2008, l'identificatore di transazione non deve nemmeno essere indovinato, poiché è prevedibile sin dall'inizio (inizialmente viene impostato a 1, che viene incrementato ad ogni richiesta, invece di essere scelto casualmente).
Nelle specifiche per la protezione contro il brute force dell'identificatore, si raccomanda di utilizzare una distribuzione casuale dei numeri delle porte di rete sorgente da cui vengono inviati i richieste DNS, per compensare la dimensione non sufficientemente grande dell'identificatore. Attivando la randomizzazione delle porte per generare una risposta fittizia, oltre a dover indovinare l'identificatore a 16 bit, è necessario anche conoscere il numero della porta di rete. In uClibc e uClibc-ng, tale randomizzazione non era attivata esplicitamente (quando si chiamava bind, non era specificata una porta UDP sorgente casuale) e il suo utilizzo dipendeva dalle impostazioni del sistema operativo.
Disattivando la randomizzazione delle porte, la determinazione dell'identificatore di richiesta incrementato è considerata un compito banale. Ma anche nel caso si utilizzi la randomizzazione, l'attaccante deve semplicemente indovinare la porta di rete all'interno dell'intervallo 32768–60999, per cui è possibile utilizzare l'invio massiccio simultaneo di risposte fittizie su diverse porte di rete.
È stata confermata la presenza di un problema in tutte le versioni attuali di uClibc e uClibc-ng, comprese le ultime versioni di uClibc 0.9.33.2 e uClibc-ng 1.0.40. A settembre 2021, le informazioni sulla vulnerabilità sono state inviate a CERT/CC per la preparazione coordinata delle patch. A gennaio 2022, i dati sul problema sono stati forniti a oltre 200 produttori che collaborano con CERT/CC. A marzo, è stato tentato un contatto diretto con il manutentore del progetto uClibc-ng, ma ha risposto di non essere in grado di risolvere la vulnerabilità da solo e ha raccomandato di divulgare pubblicamente l'informazione sul problema, sperando di ricevere supporto dalla comunità per lo sviluppo di una patch. Tra i produttori, NETGEAR ha annunciato il rilascio di un aggiornamento per risolvere la vulnerabilità.
Fonte: opennet.ru
