Dans les bibliothèques standards C uClibc et uClibc-ng, utilisées dans de nombreux appareils embarqués et portables, une vulnérabilité a été identifiée (CVE non attribuée) qui permet d'insérer des données fictives dans le cache DNS, qui peuvent être utilisées pour remplacer l'adresse IP. d'un domaine arbitraire dans le cache et rediriger les requêtes vers le domaine sur le serveur de l'attaquant.
Le problème affecte divers micrologiciels Linux pour les routeurs, les points d'accès et les appareils Internet des objets, ainsi que les distributions Linux intégrées telles que OpenWRT et Embedded Gentoo. Il est à noter que la vulnérabilité apparaît dans les appareils de nombreux fabricants (par exemple, uClibc est utilisé dans les micrologiciels Linksys, Netgear et Axis), mais comme la vulnérabilité reste non corrigée dans uClibc et uClibc-ng, des informations détaillées sur les appareils spécifiques et les fabricants dont les produits Le problème est disponible et n'a pas encore été divulgué.
La vulnérabilité est due à l'utilisation d'identifiants de transaction prévisibles dans le code d'envoi des requêtes DNS. Le numéro d'identification de la requête DNS a été choisi en augmentant simplement le compteur sans recourir à une randomisation supplémentaire des numéros de port, ce qui a permis d'empoisonner le cache DNS par l'envoi préemptif de paquets UDP avec des réponses fictives (la réponse sera acceptée si elle est arrivée avant la réponse du serveur réel et inclut l'ID correct). Contrairement à la méthode Kaminsky proposée en 2008, l'identifiant de la transaction n'a même pas besoin d'être deviné, puisqu'il est initialement prévisible (la valeur est initialement fixée à 1, qui est incrémentée à chaque requête, plutôt que choisie aléatoirement).
Pour se protéger contre la force brute de l'identifiant, la spécification recommande en outre d'utiliser une répartition aléatoire du nombre de ports réseau sources à partir desquels les requêtes DNS sont envoyées, ce qui compense la taille insuffisamment grande de l'identifiant. Lorsque vous activez la randomisation des ports pour générer une réponse fictive, en plus de sélectionner un identifiant 16 bits, vous devez également sélectionner 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 utilisation dépendait des paramètres du système d'exploitation.
Lorsque la randomisation du pot est désactivée, la détermination de l'ID de demande incrémenté est marquée comme une tâche triviale. Mais même si la randomisation est utilisée, l'attaquant n'a qu'à deviner le port réseau compris entre 32768 60999 et XNUMX XNUMX, pour lequel il peut utiliser l'envoi simultané et massif de réponses fictives vers différents ports réseau.
Le problème a été confirmé dans toutes les versions actuelles d'uClibc et uClibc-ng, y compris les versions les plus récentes d'uClibc 0.9.33.2 et uClibc-ng 1.0.40. En septembre 2021, des informations sur la vulnérabilité ont été envoyées au CERT/CC pour une préparation coordonnée des correctifs. En janvier 2022, les données sur le problème ont été partagées avec plus de 200 fabricants collaborant avec le CERT/CC. En mars, il y a eu une tentative de contacter séparément le responsable du 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 informations sur le problème, dans l'espoir de recevoir de l'aide pour développer un correctif de la communauté. Parmi les fabricants, NETGEAR a annoncé la sortie d'une mise à jour qui élimine la vulnérabilité.
Source: opennet.ru