Une vulnérabilité dans uClibc et uClibc-ng permet de falsifier les données dans le cache DNS.

Des vulnérabilités ont été détectées dans les bibliothèques standard C uClibc et uClibc-ng, utilisées dans de nombreux appareils embarqués et portables, permettant d'injecter des données fictives dans le cache DNS. Cela peut être exploité pour substituer l'adresse IP d'un domaine arbitraire dans le cache et rediriger les requêtes vers un serveur malveillant.

Le problème concerne divers firmwares Linux pour routeurs, points d'accès et appareils de l'Internet des objets, ainsi que des distributions Linux pour systèmes embarqués, telles que OpenWRT et Embedded Gentoo. Il a été noté que la vulnérabilité se manifeste dans les appareils de nombreux fabricants (par exemple, uClibc est utilisé dans les firmwares Linksys, Netgear et Axis), mais comme la vulnérabilité dans uClibc et uClibc-ng reste non corrigée, les détails concernant les appareils et fabricants spécifiquement touchés ne sont pas encore divulgués.

La vulnérabilité est causée par l'utilisation dans le code des requêtes DNS d'identifiants de transaction prévisibles. L'identifiant de la requête DNS était choisi en incrémentant simplement un compteur sans effectuer de randomisation supplémentaire des numéros de port, ce qui permettait d'empoisonner le cache DNS via un envoi anticipé de paquets UDP contenant des réponses fictives (la réponse sera acceptée si elle arrive avant celle de la réponse réelle et inclut un ID correct). de serveurs Contrairement à la méthode proposée en 2008 par Kaminsky, l'identifiant de transaction n'a même pas besoin d'être deviné, car il est à l'origine prévisible (il commence par une valeur de 1, qui est incrémentée à chaque requête, au lieu d'être choisie aléatoirement).

Dans la spécification pour se protéger contre la prédiction de l'identifiant, il est recommandé d'appliquer en plus une distribution aléatoire des numéros de ports réseau sources à partir desquels les requêtes DNS sont envoyées, ce qui compense la taille insuffisante de l'identifiant. Avec l'activation de la randomisation des ports pour générer une réponse fictive, il est nécessaire de prédire non seulement l'identifiant de 16 bits, mais également le numéro de port réseau. Dans uClibc et uClibc-ng, une telle randomisation n'était pas explicitement activée (lors de l'appel de bind, un port UDP source aléatoire n'était pas spécifié) et son application dépendait des paramètres du système d'exploitation.

Lorsque la randomisation des ports est désactivée, la détermination de l'identifiant de requête incrémentiel est considérée comme une tâche triviale. Cependant, même en cas de randomisation, l'attaquant doit simplement deviner le port réseau dans la plage de 32768 à 60999, ce qui peut être réalisé par l'envoi massif simultané de réponses fictives sur différents ports réseau.

Le problème a été confirmé dans toutes les versions récentes de uClibc et uClibc-ng, y compris les versions les plus récentes uClibc 0.9.33.2 et uClibc-ng 1.0.40. En septembre 2021, des informations sur la vulnérabilité ont été envoyées à CERT/CC pour une préparation coordonnée des correctifs. En janvier 2022, les détails sur le problème ont été transmis à plus de 200 fabricants collaborant avec CERT/CC. En mars, une tentative a été faite pour contacter séparément le projet uClibc-ng, mais il a répondu qu'il n'était pas en mesure de corriger la vulnérabilité par lui-même et a recommandé de divulguer publiquement les détails du problème, espérant recevoir de l'aide de la communauté pour développer un correctif. Parmi les fabricants, NETGEAR a annoncé la sortie d'une mise à jour corrigeant la vulnérabilité.

Source : opennet.ru