En las bibliotecas estándar de C uClibc y uClibc-ng, utilizadas en muchos dispositivos integrados y portátiles, se ha detectado una vulnerabilidad (CVE no asignado) que permite insertar datos falsos en la caché DNS, lo que puede utilizarse para reemplazar en la caché la dirección IP de un dominio arbitrario y redirigir las solicitudes al dominio a un servidor controlado por un atacante.
El problema afecta a varios firmware de Linux para enrutadores, puntos de acceso y dispositivos de Internet de las cosas, así como a distribuciones de Linux para sistemas integrados, como OpenWRT y Embedded Gentoo. Se ha observado que la vulnerabilidad se manifiesta en dispositivos de muchos fabricantes (por ejemplo, uClibc se utiliza en los firmware de Linksys, Netgear y Axis), pero dado que la vulnerabilidad en uClibc y uClibc-ng permanece sin solucionar, no se divulgan detalles sobre dispositivos y fabricantes específicos que tienen el problema en sus productos por el momento.
La vulnerabilidad se debe al uso en el código de envío de solicitudes DNS de identificadores de transacción predecibles. El número de identificación de la solicitud DNS se seleccionaba mediante un simple incremento de un contador sin aplicar una aleatorización adicional de los números de puerto, lo que permitía lograr el envenenamiento de la caché DNS a través del envío anticipado de paquetes UDP con respuestas falsas (la respuesta será aceptada si llega antes que la respuesta real y contiene un ID válido). servidores A diferencia del método de Kaminsky propuesto en 2008, el identificador de transacción ni siquiera necesita ser adivinado, ya que es originalmente predecible (se establece inicialmente en 1, el cual se incrementa con cada solicitud, en lugar de ser seleccionado aleatoriamente).
En la especificación para proteger contra la adivinanza del identificador, se recomienda aplicar una distribución aleatoria de los números de puertos de red de origen desde los cuales se envían las solicitudes DNS, lo que compensa el tamaño insuficientemente grande del identificador. Al habilitar la aleatorización de puertos para generar respuestas falsas, además de adivinar un identificador de 16 bits, también es necesario adivinar el número del puerto de red. En uClibc y uClibc-ng, tal aleatorización no se habilitó explícitamente (al llamar a bind no se especificaba un puerto UDP de origen aleatorio) y su aplicación dependía de la configuración del sistema operativo.
Al desactivar la aleatorización de las conexiones, identificar el identificador incremental de la solicitud se marca como una tarea trivial. Pero incluso en el caso de utilizar aleatorización, el atacante solo necesita adivinar el puerto de red dentro del rango de 32768 a 60999, para lo cual puede utilizar el envío masivo simultáneo de respuestas falsas a través de diferentes puertos de red.
El problema ha sido confirmado en todas las versiones recientes de uClibc y uClibc-ng, incluidas las versiones más recientes uClibc 0.9.33.2 y uClibc-ng 1.0.40. En septiembre de 2021, la información sobre la vulnerabilidad fue enviada a CERT/CC para la preparación coordinada de correcciones. En enero de 2022, los datos sobre el problema fueron transmitidos a más de 200 fabricantes que colaboran con CERT/CC. En marzo, se intentó contactar por separado al mantenedor del proyecto uClibc-ng, pero respondió que no podía solucionar la vulnerabilidad por su cuenta y recomendó hacer pública la información sobre el problema, esperando recibir ayuda de la comunidad para desarrollar un parche. NETGEAR fue uno de los fabricantes que anunció el lanzamiento de una actualización que corrige la vulnerabilidad.
Fuente: opennet.ru
