Hace pocos dias se dio a conocer la noticia de que en las bibliotecas estándar C uClibc y uClibc-ng, utilizadas en muchos dispositivos integrados y portátiles, se ha identificado una vulnerabilidad (con CVE aun no asignado), que permite sustituir datos ficticios en la caché DNS, que pueden utilizarse para falsificar la dirección IP de un dominio arbitrario en el caché y redirigir las solicitudes al dominio al servidor del atacante.

Sobre el problema se menciona que este afecta a varios firmware de Linux para enrutadores, puntos de acceso y dispositivos IoT, así como distribuciones de Linux integradas como OpenWRT y Embedded Gentoo.

Sobre la vulnerabilidad

La vulnerabilidad se debe al uso de identificadores de transacciones predecibles en el código para enviar consultas de DNS. El ID de consulta de DNS se eligió simplemente incrementando el contador sin una aleatorización adicional de los números de puerto, lo que hizo posible envenenar la caché de DNS al enviar de forma preventiva paquetes UDP con respuestas falsas (la respuesta se aceptará si llega antes que 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 ID de la transacción, ya que inicialmente es predecible (inicialmente, se establece el valor 1, que aumenta con cada solicitud, y no se selecciona aleatoriamente).

Para protegerse contra la adivinación de ID, la especificación recomienda además el uso de una distribución aleatoria de los números de puerto de la red de origen desde los que se envían las consultas de DNS, lo que compensa el tamaño insuficiente de la ID.

Cuando la aleatorización de puertos está habilitada, para formar una respuesta ficticia, además de seleccionar un identificador de 16 bits, también es necesario seleccionar el número de puerto de red. En uClibc y uClibc-ng, dicha aleatorización no estaba explícitamente habilitada (cuando se llamaba a bind, no se especificaba un puerto UDP de origen aleatorio) y su aplicación dependía de la configuración del sistema operativo.

Cuando la aleatorización de puertos está deshabilitada, determinar qué ID de solicitud incrementar se marca como una tarea trivial. Pero incluso en el caso de la aleatorización, el atacante solo necesita adivinar el puerto de red del rango 32768-60999, para lo cual puede usar el envío simultáneo masivo de respuestas ficticias en diferentes puertos de red.

El problema se ha confirmado en todas las versiones actuales de uClibc y uClibc-ng, incluidas las últimas versiones de uClibc 0.9.33.2 y uClibc-ng 1.0.40.

“Es importante tener en cuenta que una vulnerabilidad que afecta a una biblioteca estándar de C puede ser un poco compleja”, escribió el equipo en una publicación de blog esta semana.

“No solo habría cientos o miles de llamadas a la función vulnerable en múltiples puntos de un solo programa, sino que la vulnerabilidad afectaría a una cantidad indefinida de otros programas de múltiples proveedores configurados para usar esa biblioteca”.

En septiembre de 2021, se envió información sobre la vulnerabilidad a CERT/CC para la preparación coordinada de arreglos. En enero de 2022, el problema se compartió con más de 200 fabricantes asociados con CERT/CC.

En marzo, hubo un intento de contactar por separado al mantenedor del proyecto uClibc-ng, pero respondió que no podía arreglar la vulnerabilidad por sí mismo y recomendó la divulgación pública de información sobre el problema, con la esperanza de obtener ayuda para desarrollar una solución de la comunidad. De los fabricantes, NETGEAR anunció el lanzamiento de una actualización con la eliminación de la vulnerabilidad.

Es importante tener en cuenta que una vulnerabilidad que afecta a una biblioteca estándar de C puede ser un poco compleja. No solo habría cientos o miles de llamadas a la función vulnerable en múltiples puntos de un solo programa, sino que la vulnerabilidad afectaría a una cantidad indefinida de otros programas de múltiples proveedores configurados para usar esa biblioteca.

Se observa que la vulnerabilidad se manifiesta 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 parchear en uClibc y uClibc-ng, la información detallada sobre dispositivos y fabricantes específicos en cuyos productos existe un problema, hasta que sean divulgados.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.