En las bibliotecas C estándar uClibc y uClibc-ng, utilizadas en muchos dispositivos integrados y portátiles, se ha identificado una vulnerabilidad (CVE no asignada) que permite insertar datos ficticios en la caché DNS, que pueden usarse para reemplazar la dirección IP. de un dominio arbitrario en la caché y redirigir solicitudes al dominio en el servidor del atacante.
El problema afecta a varios firmwares de Linux para enrutadores, puntos de acceso y dispositivos de Internet de las cosas, así como a distribuciones de Linux integradas como OpenWRT y Embedded Gentoo. Cabe señalar que la vulnerabilidad aparece en dispositivos de muchos fabricantes (por ejemplo, uClibc se usa en el firmware de Linksys, Netgear y Axis), pero dado que la vulnerabilidad permanece sin corregir en uClibc y uClibc-ng, se proporciona información detallada sobre dispositivos y fabricantes específicos cuyos productos. El problema está disponible, aún no se ha revelado.
La vulnerabilidad se debe al uso de identificadores de transacciones predecibles en el código para enviar consultas DNS. El número de identificación de la solicitud DNS se eligió simplemente aumentando el contador sin utilizar una aleatorización adicional de los números de puerto, lo que permitió envenenar el caché DNS mediante el envío preventivo de paquetes UDP con respuestas ficticias (la respuesta será aceptada si llegó antes la respuesta del servidor real e incluye la identificación correcta). A diferencia del método Kaminsky propuesto en 2008, ni siquiera es necesario adivinar el identificador de la transacción, ya que inicialmente es predecible (el valor se establece inicialmente en 1, que aumenta con cada solicitud, en lugar de elegirse al azar).
Para protegerse contra la fuerza bruta del identificador, la especificación recomienda utilizar adicionalmente una distribución aleatoria del número de puertos de red de origen desde los que se envían las solicitudes DNS, lo que compensa el tamaño insuficientemente grande del identificador. Cuando habilita la aleatorización de puertos para generar una respuesta ficticia, además de seleccionar un identificador de 16 bits, también debe seleccionar el número de puerto de red. En uClibc y uClibc-ng, dicha aleatorización no estaba habilitada explícitamente (al llamar a bind, no se especificaba un puerto UDP de origen aleatorio) y su uso dependía de la configuración del sistema operativo.
Cuando la aleatorización del bote está deshabilitada, determinar el ID de solicitud incrementado se marca como una tarea trivial. Pero incluso si se utiliza la aleatorización, el atacante sólo necesita adivinar el puerto de red entre 32768 y 60999, para lo cual puede utilizar el envío simultáneo masivo de respuestas ficticias a diferentes puertos de red.
El problema se ha confirmado en todas las versiones actuales de uClibc y uClibc-ng, incluidas las versiones más recientes de uClibc 0.9.33.2 y uClibc-ng 1.0.40. En septiembre de 2021, se envió información sobre la vulnerabilidad al CERT/CC para la preparación coordinada de correcciones. En enero de 2022, se compartieron datos sobre el problema con más de 200 fabricantes que colaboran con CERT/CC. En marzo, hubo un intento de contactar por separado al responsable del proyecto uClibc-ng, pero él respondió que no podía solucionar la vulnerabilidad por sí solo y recomendó revelar públicamente información sobre el problema, con la esperanza de recibir ayuda para desarrollar un arreglo de la comunidad. Entre los fabricantes, NETGEAR anunció el lanzamiento de una actualización que elimina la vulnerabilidad.
Fuente: opennet.ru