Il y a quelques jours, on a appris que dans les bibliothèques standard C uClibc et uClibc-ng, utilisé dans de nombreux appareils embarqués et portables, une vulnérabilité a été identifiée (avec CVE non encore attribué), qui permet la substitution de données factices dans le cache DNS, qui peuvent être utilisées pour usurper l'adresse IP d'un domaine arbitraire dans le cache et rediriger les requêtes vers le domaine vers le serveur de l'attaquant.
À propos du problème, il est mentionné que cela affecte divers micrologiciels Linux pour les routeurs, les points d'accès et les appareils IoT, ainsi que des distributions Linux embarquées comme OpenWRT et Embedded Gentoo.
À propos de la vulnérabilité
Vulnérabilité est dû à l'utilisation d'identifiants de transaction prévisibles dans le code pour envoyer des requêtes du DNS. L'ID de requête DNS a été choisi en incrémentant simplement le compteur sans autre randomisation des numéros de port, ce qui a permis d'empoisonner le cache DNS en envoyant de manière préemptive des paquets UDP avec de fausses réponses (la réponse sera acceptée si elle arrive avant la réponse du vrai serveur et inclut l'identification correcte).
Contrairement à la méthode Kaminsky proposée en 2008, il n'est même pas nécessaire de deviner l'ID de transaction, puisqu'il est initialement prévisible (initialement, il est fixé à 1, qui augmente à chaque requête, et n'est pas sélectionné au hasard).
Pour te protéger contre la devinette d'identité, la spécification recommande en outre l'utilisation d'une distribution aléatoire des numéros de port réseau d'origine à partir duquel les requêtes DNS sont envoyées, ce qui compense la taille insuffisante de l'ID.
Lorsque la randomisation des ports est activée, pour former une réponse fictive, en plus de sélectionner un identifiant 16 bits, il est également nécessaire de sélectionner le numéro de port réseau. Dans uClibc et uClibc-ng, une telle randomisation n'était pas explicitement activée (lorsque la liaison était appelée, un port UDP source aléatoire n'était pas spécifié) et sa mise en œuvre dépendait de la configuration du système d'exploitation.
Lorsque la randomisation des ports est désactivée, la détermination de l'ID de demande à incrémenter est marquée comme une tâche triviale. Mais même dans le cas de la randomisation, l'attaquant n'a qu'à deviner le port réseau parmi la plage 32768-60999, pour laquelle il peut utiliser l'envoi simultané massif de réponses factices sur différents ports réseau.
Le problème a été confirmé dans toutes les versions actuelles de uClibc et uClibc-ng, y compris les dernières versions de uClibc 0.9.33.2 et uClibc-ng 1.0.40.
"Il est important de noter qu'une vulnérabilité affectant une bibliothèque C standard peut être assez complexe", a écrit l'équipe dans un article de blog cette semaine.
"Non seulement il y aurait des centaines ou des milliers d'appels à la fonction vulnérable à plusieurs points dans un seul programme, mais la vulnérabilité affecterait un nombre indéfini d'autres programmes multi-fournisseurs configurés pour utiliser cette bibliothèque."
En septembre 2021, des informations sur la vulnérabilité ont été envoyées au CERT/CC pour la préparation coordonnée de la matrice. En janvier 2022, le problème a été partagé avec plus de 200 fabricants associé au 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 ne pouvait pas corriger lui-même la vulnérabilité et a recommandé la divulgation publique d'informations sur le problème, dans l'espoir d'obtenir de l'aide pour développer un correctif. la communauté. Du côté des fabricants, NETGEAR a annoncé la sortie d'une mise à jour avec la suppression de la vulnérabilité.
Il est important de noter qu'une vulnérabilité affectant une bibliothèque C standard peut être assez complexe. Non seulement il y aurait des centaines ou des milliers d'appels à la fonction vulnérable à plusieurs points dans un seul programme, mais la vulnérabilité affecterait un nombre indéfini d'autres programmes de plusieurs fournisseurs configurés pour utiliser cette bibliothèque.
Il est à noter que la vulnérabilité se manifeste dans les appareils de nombreux fabricants (par exemple, uClibc est utilisé dans les micrologiciels de 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 et des informations spécifiques fabricants dont les produits présentent un problème, jusqu'à ce qu'ils soient divulgués.
Enfin si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant.