Nelle librerie standard C uClibc e uClibc-ng, utilizzate in molti dispositivi embedded e portatili, è stata rilevata una vulnerabilità (CVE non assegnato) che consente di inserire dati falsi nella cache DNS, che possono essere utilizzati per sostituire l'indirizzo IP di un dominio a piacere e reindirizzare le richieste al dominio su un server di un attaccante.
Il problema riguarda vari firmware Linux per router, punti di accesso e dispositivi IoT, così come distribuzioni Linux per sistemi embedded come OpenWRT e Embedded Gentoo. Si osserva che la vulnerabilità si manifesta in dispositivi di molti produttori (ad esempio, uClibc è usato nei firmware di Linksys, Netgear e Axis), ma poiché uClibc e uClibc-ng non hanno ancora corretto la vulnerabilità, i dettagli specifici riguardanti i dispositivi e i produttori nei cui prodotti è presente il problema non sono attualmente divulgati.
La vulnerabilità è causata dall'uso di identificatori di transazione prevedibili nel codice per l'invio di richieste DNS. L'identificativo della richiesta DNS veniva scelto semplicemente incrementando un contatore senza applicare ulteriore randomizzazione ai numeri di porta, il che consentiva l'avvelenamento della cache DNS tramite l'invio preventivo di pacchetti UDP con risposte false (la risposta viene accettata se arriva prima della risposta reale e include un ID corretto). server A differenza del metodo di Kaminsky proposto nel 2008, l'identificatore di transazione non deve nemmeno essere indovinato, poiché è inizialmente prevedibile (inizialmente è impostato su 1, che viene incrementato con ogni richiesta, e non scelto casualmente).
Nella specifica per proteggere contro la previsione degli identificatori, si raccomanda di applicare ulteriormente una distribuzione casuale dei numeri di porta di rete di origine da cui vengono inviati i pacchetti DNS, il che compensa la dimensione insufficiente dell'identificatore. Quando viene attivata la randomizzazione delle porte per la composizione di una risposta falsa, è necessario indovinare, oltre all'identificatore di 16 bit, anche il numero della porta di rete. In uClibc e uClibc-ng, tale randomizzazione non era esplicitamente integrata (alla chiamata bind non veniva specificata una porta UDP di origine casuale) e il suo utilizzo dipendeva dalle impostazioni del sistema operativo.
Disattivando la randomizzazione dei porti, la determinazione dell'identificatore incrementale della richiesta è considerata un compito triviale. Ma anche nel caso venga utilizzata la randomizzazione, l'attaccante deve solo indovinare la porta di rete da un intervallo di 32768–60999, il che può essere fatto utilizzando un invio massiccio e simultaneo di risposte fasulle su diverse porte di rete.
Il problema è stato confermato in tutte le versioni attuali di uClibc e uClibc-ng, comprese le versioni più recenti 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 coordinare la preparazione delle patch. A gennaio 2022, i dettagli sul problema sono stati comunicati a oltre 200 produttori che collaborano con CERT/CC. A marzo, è stato tentato di contattare separatamente il progetto uClibc-ng, ma hanno risposto di non essere in grado di risolvere autonomamente la vulnerabilità e hanno raccomandato di divulgare pubblicamente le informazioni sul problema, sperando di ricevere assistenza dalla comunità per sviluppare una patch. Tra i produttori, NETGEAR ha annunciato il rilascio di un aggiornamento per risolvere la vulnerabilità.
Fonte: opennet.ru
