DNSpooq - Plusieurs vulnérabilités dans dnsmasq (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686, CVE-2020-25687)

Récapitulatif

Red Hat est au courant de plusieurs problèmes dans dnsmasq qualifiés de DNSpooq. Dnsmasq est un outil léger conçu pour fournir des services réseau, notamment DNS et DHCP, aux petits réseaux privés et aux environnements de virtualisation. Ces problèmes se trouvent dans le service DNS (Domain Name System) de dnsmasq. Ces vulnérabilités pourraient être utilisées par un attaquant à distance, ayant un certain degré de contrôle sur un système client de dnsmasq, pour rediriger les utilisateurs vers de mauvais sites ou pour exécuter du code sur la machine qui héberge dnsmasq.

Deux de ces vulnérabilités (CVE-2020-25681 et CVE-2020-25682) ont été classées avec un impact de gravité de Important en raison de la possibilité d'exécuter du code à distance sur une machine dnsmasq. Les CVE-2020-25683, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686, et CVE-2020-25687 ont été classées avec un impact de gravité Modéré

CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 et CVE-2020-25687 exigent que la DNSSEC soit compilée et activée dans la configuration dnsmasq. En conséquence, les versions suivantes du produit Red Hat sont impactées lors de l'utilisation d'une configuration non par défaut :

• Red Hat Enterprise Linux 8

CVE-2020-25684, CVE-2020-25685, et CVE-2020-25686 peuvent permettre à un attaquant de compromettre le cache du DNS et de rediriger les utilisateurs victimes vers de mauvais sites. Les versions de produits Red Hat suivants sont affectées :

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

Les produits Red Hat suivants sont potentiellement affectés lorsqu'ils retirent dnsmasq du canal Red Hat Enterprise Linux. Veuillez vous assurer que le paquet dnsmasq de Red Hat Enterprise Linux sous-jacent est à jour et vous référer au cas d'utilisation de libvirt pour plus d'informations.

• Red Hat OpenStack Platform 10

• Red Hat OpenStack Platform 13

• Red Hat Virtualization 4.3

• Red Hat Virtualization 4.4

• Red Hat OpenShift Container Platform 3.11

Pour déterminer si votre système est actuellement concerné par ces failles de sécurité, voir la section Diagnostic ci-dessous.

Résumé technique

Ces sept failles de dnsmasq se divisent en deux groupes :

• Failles qui permettent à dnsmasq de faire correspondre les réponses DNS entrantes avec les requêtes précédemment transmises (CVE-2020-25684, CVE-2020-25685 et CVE-2020-25686).

• Failles avec des dépassements de capacité de la mémoire tampon dans le code qui prépare les données DNSSEC pour la validation (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 et CVE-2020-25687).

Pour exploiter ce deuxième groupe de vulnérabilités, un attaquant a besoin de la collaboration d'un client dnsmasq ou d'autres moyens pour faire en sorte qu'un client lance une série de requêtes DNS à dnsmasq pour un domaine contrôlé par l'attaquant.

Le premier groupe de failles peut principalement être utilisé pour effectuer facilement une attaque qui compromette le cache DNS ayant un impact sur tous les clients qui utilisent dnsmasq comme serveur DNS, en leur fournissant de mauvaises résolutions de noms pour les entrées compromettantes. Lorsque les failles s’enchaînent, l'attaque peut être réalisée en quelques minutes.

Le deuxième groupe de vulnérabilités exige que DNSSEC soit activé dans dnsmasq et peut être déclenché avant que les données DNSSEC ne soient validées en envoyant une réponse élaborée à une requête ouverte transmise.

Le résultat final de l'exploitation réussie varie également en fonction de la vulnérabilité. Pour CVE-2020-25681 et CVE-2020-25682, une exécution de code à distance peut avoir lieu sur la machine hôte et, par conséquent, avoir un impact de gravité Important. CVE-2020-25683 et CVE-2020-25687 n'entraînent qu'une panne du service dnsmasq et enregistrent un impact de gravité Modéré.

Veuillez noter que même si dnsmasq n'est pas initié par l'utilisateur, il peut être automatiquement exécuté par libvirt pour fournir un service DNS aux machines virtuelles invitées. De plus, NetworkManager peut être configuré à utiliser dnsmasq pour fournir le DNS au système.

Reportez-vous à la section Contexte pour obtenir plus de détails sur les vulnérabilités.

Mesures de mitigation

L'impact des CVE-2020-25684, CVE-2020-25685, et CVE-2020-25686 peut être réduit en désactivant le cache dnsmasq en ajoutant `--cache-size=0` lors de l'invocation de dnsmasq ou en ajoutant une ligne `cache-size=0` au fichier de configuration dnsmasq (/etc/dnsmasq.conf par défaut).

Lorsque vous utilisez Red Hat Enterprise Linux 8.3 avec libvirt via un module virt:rhel, utilisez `virsh net-edit <network-name>` et faites référence à https://libvirt.org/formatnetwork.html#elementsNamespaces pour ajouter l'option suggérée `cache-size=0`.

Lors de l'utilisation de versions de Red Hat Enterprise Linux antérieures à la version 8.3, il n'est pas possible de personnaliser la configuration dnsmasq générée par libvirt. Si dnsmasq est exécuté via NetworkManager, créez un nouveau fichier dans /etc/NetworkManager/dnsmasq.d/ et ajoutez-y `cache-size=0`.

Dans tous les cas, en désactivant le cache, vous pouvez souffrir d’une perte de performance dans votre environnement en raison de la transmission de toutes les requêtes DNS aux serveurs en amont. Veuillez évaluer si la mesure de mitigation est appropriée pour l'environnement du système avant de faire votre demande.

La seule façon connue de limiter les dégâts de CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 et CVE-2020-25687 est de désactiver complètement la DNSSEC, en supprimant l'option de ligne de commande `--dnssec` ou l'option `dnssec` du fichier de configuration dnsmasq.

Nous recommandons d'appliquer les mises à jour de dnsmasq dès qu'elles sont disponibles.

Détails techniques

CVE-2020-25681

Un dépassement de capacité de la mémoire tampon « heap-based » a été découvert dans la façon dont les RRSets sont triés avant d'être validés avec les données DNSSEC. Un attaquant sur le réseau, qui peut forger des réponses DNS telles qu'elles sont acceptées comme valides, peut utiliser cette faille pour provoquer un dépassement de capacité de la mémoire tampon avec des données arbitraires, dans un segment de mémoire de tas (heap), en exécutant éventuellement du code sur la machine.

CVE-2020-25682

Une vulnérabilité liée à un dépassement de capacité de la mémoire tampon a été découverte dans la manière dont dnsmasq extrait les noms des paquets DNS avant de les valider avec des données DNSSEC. Un attaquant sur le réseau, en mesure de forger des réponses DNS acceptées comme valides, peut utiliser cette faille pour provoquer un dépassement de capacité de la mémoire tampon avec des données arbitraires dans un segment de mémoire de tas (heap), en exécutant éventuellement du code sur la machine. La faille se trouve dans la fonction rfc1035.c:extract_name(), qui inscrit les données dans la mémoire pointée par le nom en supposant que des octets MAXDNAME*2 sont disponibles dans la mémoire tampon. Cependant, dans certains chemins d'exécution du code, il est possible que extract_name() reçoive un déport du tampon de base, réduisant ainsi, en pratique, le nombre d'octets disponibles qui peuvent être inscrits dans le tampon.

CVE-2020-25683

Un dépassement de capacité de la mémoire tampon « heap-based » a été découvert dans dnsmasq lorsque DNSSEC est activé et avant qu'il ne valide les entrées DNS reçues. Un attaquant distant, qui peut créer des réponses DNS valides, peut utiliser cette faille pour provoquer un dépassement de capacité de la mémoire allouée « heap-based ». Cette faille est due à l'absence de contrôles de longueur dans rfc1035.c:extract_name(), qui pourrait être exploité pour faire exécuter au code memcpy() avec une taille négative dans get_rdata() et provoquer un crash dans dnsmasq, entraînant un déni de service.

CVE-2020-25684

Lorsqu'il reçoit une réponse d'une requête transmise, dnsmasq vérifie dans forward.c:reply_query() si l'adresse/le port de destination de la réponse est utilisé(e) par les requêtes transmises en attente. Cependant, il n'utilise pas l'adresse/le port pour récupérer la requête exacte telle qu’elle est transmise, ce qui réduit considérablement le nombre de tentatives qu'un attaquant sur le réseau doit effectuer pour forger une réponse et la faire accepter par dnsmasq. Ce problème contraste avec la RFC5452, qui spécifie les attributs d'une requête qui doivent tous être utilisés pour correspondre à une réponse. Cette faille permet à un attaquant d'effectuer une attaque de compromission du cache (DNS Cache Poisoning). Si elle est enchaînée par CVE-2020-25685 ou CVE-2020-25686, la complexité d'une attaque réussie est réduite.

CVE-2020-25685

Lorsqu'il reçoit une réponse à une requête transmise, dnsmasq vérifie dans forward.c:reply_query() la requête transmise qui correspond à la réponse, en utilisant seulement un hachage faible du nom de la requête. En raison de la faiblesse du hachage (CRC32 lorsque dnsmasq est compilé sans DNSSEC, SHA-1 lorsqu'il l'est avec), cette faille permet à un attaquant hors-chemin de trouver plusieurs domaines différents ayant tous le même hachage, réduisant considérablement le nombre de tentatives qu'il doit effectuer pour forger une réponse et la faire accepter par dnsmasq. Cela contraste avec la RFC5452, qui précise que le nom de la requête est l'un des attributs d'une requête qui doit être utilisé pour correspondre à une réponse. Cette faille permet à un attaquant d'effectuer une attaque de compromission du cache (DNS Cache Poisoning). Si elle est enchaînée par CVE-2020-25684 ou CVE-2020-25686, la complexité d'une attaque réussie est réduite.

CVE-2020-25686

Lorsqu'il reçoit une demande, le dnsmasq ne vérifie pas si une demande existante du même nom est en attente et transmet une nouvelle demande. Par défaut, un maximum de 150 requêtes en attente peuvent être envoyées aux serveurs en amont, de sorte qu'il peut y avoir au maximum 150 requêtes ayant le même nom. Cette faille permet à un attaquant hors-chemin sur le réseau de réduire considérablement le nombre de tentatives qu'il doit effectuer pour forger une réponse et la faire accepter par dnsmasq. Ce problème est mentionné dans la section "Birthday Attacks" de RFC5452. Si poursuivie par CVE-2020-25684, la complexité d’une attaque réussie est réduite.

CVE-2020-25687

Un dépassement de capacité de la mémoire tampon « heap-based » a été découvert dans dnsmasq lorsque DNSSEC est activé et avant qu'il ne valide les entrées DNS reçues. Cette faille permet à un attaquant distant de créer des réponses DNS valides provoquant un dépassement de capacité de la mémoire allouée « heap-based ». Cette faille est due à l'absence de contrôles de longueur dans rfc1035.c:extract_name(), pouvant ainsi être exploité pour faire exécuter au code memcpy() avec une taille négative dans get_rdata() et provoquer un crash dans dnsmasq, entraînant un déni de service.

Contexte

Le système de noms de domaine (DNS) est principalement utilisé pour traduire les noms de domaine (par exemple, www.example.com) en adresses IP (par exemple 127.0.0.1 et 2001:DB8::/1). Il est organisé comme un système distribué, sans qu'un seul nœud ne connaisse tous les domaines et toutes les traductions. La résolution d'un nom unique peut nécessiter plusieurs requêtes et réponses de la part de plusieurs serveurs jusqu'à ce que le serveur de noms qui connaît le nom demandé soit atteint. L'ensemble de ce processus est connu sous le nom de processus de résolution DNS.

Le DNS a plusieurs limites de sécurité, et en particulier, il ne peut garantir qu'aucun des serveurs concernés ou d'autres attaquants externes ne fourniront de réponses falsifiées. Il utilise principalement un identifiant aléatoire de 16 bits dans la réponse/interrogation DNS et un port source UDP aléatoire comme moyen d'empêcher les attaquants externes de détourner la communication. La DNSSEC a été développée pour ajouter une couche au-dessus du DNS afin de fournir une authentification d'origine et une assurance d'intégrité aux données du DNS. Si utilisée, cette méthode associe une signature aux données réelles du DNS qui peuvent être vérifiées par d'autres systèmes pour s'assurer que la réponse fournie provient bien du serveur faisant autorité pour ce domaine et qu'elle n'a pas été falsifiée par quelqu'un d'autre. Si appliquée, la validation DNSSEC empêche les attaques compromettant le cache du DNS, mais son adoption n'est pas encore généralisée.

Dnsmasq est un outil léger qui fournit une infrastructure de réseau pour les petits réseaux et, en particulier, il fournit des services DNS et DHCP. Son service DNS est principalement utilisé pour le réacheminement, qui reçoit les requêtes DNS des clients, les transmet à un ensemble de serveurs DNS en amont préconfigurés et met ensuite les réponses en cache de sorte que la prochaine fois que la même requête est faite par un même client ou par un autre, une réponse peut être renvoyée immédiatement sans qu'il soit nécessaire de la redemander au serveur en amont. Peut également être configuré pour effectuer une validation DNSSEC.

Les vulnérabilités CVE-2020-25684, CVE-2020-25685 et CVE-2020-25686 peuvent être utilisées par un attaquant, qui aurait également une sorte de contrôle sur un client dnsmasq, pour élaborer des réponses DNS et compromettre dnsmasq afin qu'il les accepte, comme si elles provenaient des serveurs DNS en amont préconfigurés. Lorsque le cache est activé (comportement par défaut), ces mauvaises réponses sont mises en cache et servies à d'autres clients également, les redirigeant vers des sites potentiellement malveillants. Ce problème est connu sous le nom « DNS Cache Poisoning attack ». Ces failles réduisent considérablement le nombre de tentatives qu'un attaquant doit effectuer pour deviner l'identifiant 16 bits et le port UDP spécifique utilisé pour une requête DNS particulière. Étant donné que l'attaque n'est pas déterministe et qu'il faut un certain temps pour deviner la bonne combinaison de valeurs, un attaquant a besoin d'un client dnsmasq pour commencer à effectuer de nombreuses requêtes DNS vers un domaine choisi par l'attaquant (par exemple, un utilisateur victime visite un site web malveillant qui déclenche le processus de résolution DNS via le navigateur, l'attaquant a le contrôle d'un système client ou peut en compromettre un).

Lorsque le dnsmasq est configuré pour utiliser DNSSEC, il devient vulnérable aux CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 et CVE-2020-25687. Ces failles peuvent être utilisées par un attaquant distant, qui a également une sorte de contrôle sur un client dnsmasq, pour exécuter à distance du code sur le système qui exécute dnsmasq ou pour le faire planter, provoquant un déni de service pour les clients dnsmasq, qui ne seraient plus en mesure de résoudre les noms de domaine.

Impact sur les produits

Red Hat Enterprise Linux 8

Par défaut, le service dnsmasq systemd est désactivé et NetworkManager n'est pas configuré pour l'utiliser.

Les versions de dnsmasq livrées avec Red Hat Enterprise Linux 8 sont concernées par tous les CVE annoncés dans cet article. Toutefois, dans sa configuration par défaut, Red Hat Enterprise Linux 8 n'active pas DNSSEC et n'est donc pas concerné par les normes CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 et CVE-2020-25687.

Red Hat Enterprise Linux 7 / Red Hat Enterprise Linux 6

Par défaut, le service dnsmasq systemd est désactivé et NetworkManager n'est pas configuré pour l'utiliser.

Les versions de dnsmasq livrées avec Red Hat Enterprise Linux 6 et 7 sont concernées par les vulnérabilités CVE-2020-25684, CVE-2020-25685, et CVE-2020-25686.

Red Hat Enterprise Linux 6 et 7 ne sont pas affectés par les autres vulnérabilités, car DNSSEC n'est pas compilé dans les paquets dnsmasq.

Cas d'utilisation de Libvirt

À moins qu'il ne soit explicitement désactivé, dnsmasq est utilisé pour fournir des services DNS aux invités de libvirt, en utilisant les résolveurs du système comme serveurs DNS en amont. Un attaquant ayant le contrôle d'un système invité ou ayant la possibilité de manipuler un système invité en effectuant de multiples requêtes DNS vers un domaine contrôlé par l'attaquant, peut utiliser les CVE-2020-25684, CVE-2020-25685 et CVE-2020-25686 pour comprometter le cache dnsmasq et affecter tous les invités connectés au même réseau virtuel. À moins que DNSSEC ne soit configuré manuellement, le dnsmasq utilisé dans libvirt n'est pas vulnérable aux CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 et CVE-2020-25687.

Impact des services

Pour tous les clusters OpenShift v3, y compris : Red Hat OpenShift Online, OpenShift Dedicated, Microsoft Azure Red Hat OpenShift :

Dnsmasq est utilisé dans OpenShift Dedicated v3. Le dnsmasq utilisé dans les clusters OpenShift v3 est livré par le paquet Red Hat Enterprise Linux 7, les clusters v3 ne sont pas affectés par les failles DNSSEC (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687).

Pour les failles non-DNSSEC (CVE-2020-25684, CVE-2020-25685, CVE-2020-25686), les services OpenShift Dedicated 3 sont affectés, puisqu'ils utilisent le package fourni par Red Hat Enterprise Linux 7. Chaque noeud utilise dnsmasq et il n'y a aucune protection qui puisse empêcher un attaquant d'empoisonner le cache DNS du noeud.

Red Hat prend des mesures pour mettre à jour les services afin d'atténuer cette vulnérabilité.  En attendant, pour prévenir les attaques par empoisonnement du cache en exploitant les vulnérabilités, les clients utilisant dnsmasq peuvent explicitement définir --cache-size=0 lorsqu'ils appellent dnsmasq.  Si le service exécute dnsmasq via libvirt (une API open source), les clients peuvent utiliser virsh net-edit <network-name> pour mettre à jour cache-size=0. 

Pour tous les clusters OpenShift v4, y compris le cluster dédié à OpenShift :

OpenShift Dedicated v4 utilise l'opérateur DNS (qui utilise CoreDNS) au lieu de dnsmasq. Les clusters OpenShift v4 ne sont pas affectés par les failles de dnsmasq. Nous avons vérifié qu'il n'y a pas de clusters en v4 qui utilisent dnsmasq.

Produits Red Hat affectés par ces CVE

Mises à jour des produits concernés

Nous conseillons à tous les clients de Red Hat exécutant des versions de produits Red Hat affectés de procéder aux mises à jour dès que les correctifs sont disponibles. Les clients sont invités à appliquer immédiatement les mises à jour disponibles et à activer les mesures de mitigation de l’impact qu'ils jugent appropriées.

[1] Le lien "Avis/Mise à jour" sera ajouté une fois que les mises à jour seront mises en ligne.

[2] Qu'est-ce que l'abonnement à Red Hat Enterprise Linux Extended Update Support (EUS) ?

[3] Qu'est-ce que l'Advanced mission critical Update Support (AUS) ?

[4] Qu'est-ce que l'abonnement à Red Hat Enterprise Linux SAP Solutions ?

Produits et conteneurs potentiellement concernés

Les produits et conteneurs suivants consomment des paquets affectés en provenance d’un autre produit.  Bien que Red Hat's Containers ne soit pas directement concerné par ces problèmes, leur sécurité repose sur l'intégrité et les mises à jour de l'image de base (c-a-d les mises à jour des paquets RHEL). Red Hat vous recommande d'utiliser les versions les plus récentes de vos images de conteneurs. L'index de santé des conteneurs (Container Health Index), qui fait partie du Red Hat Container Catalog, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat.

Diagnostic

Un script de détection a été développé afin de déterminer si votre système est actuellement concerné par cette faille de sécurité. Pour vérifier la légitimité du script, vous pouvez télécharger la signature GPG détachée également. Les instructions sur la manière d'utiliser la signature GPG pour la vérification sont disponibles sur le portail client.

FAQ

Q: Mon système est-il vulnérable à ces failles si dnsmasq est utilisé pour fournir le DNS sur un réseau privé ?

A: Un attaquant doit soumettre de nombreuses requêtes DNS provenant de l’intérieur même du réseau privé à l’instance dnsmasq vulnérable, car l'attaque nécessite de faire des suppositions pour contourner les protections DNS de base. Les requêtes DNS peuvent être déclenchées de plusieurs manières, allant du contrôle total d'un système sur le réseau à l’exploitation d'un utilisateur victime connecté au réseau pour qu'il ouvre un email ou un site web. Avec un nombre suffisant de requêtes DNS, ces failles pourraient être exploitées, même sur un réseau privé.

Q: Ces défauts peuvent-ils être utilisés pour effectuer une fuite d'hôte à hôte si mon système utilise libvirt ?

A: L'attaquant a besoin de la collaboration d'un des invités pour lancer une attaque qui utilise ces failles. Si l'attaquant peut lancer plusieurs requêtes DNS vers dnsmasq depuis un système invité, il est alors possible d'exploiter les failles annoncées dans cet article pour compromettre son cache. Si DNSSEC était configuré manuellement dans dnsmasq comme utilisé par libvirt (configuration non par défaut), il serait possible d'exécuter également du code ou de planter le serveur dnsmasq dans la machine hôte.

Q: Quelles sont les étapes nécessaires après la mise à niveau du paquet dnsmasq pour garantir que le système n'est pas vulnérable ?

A: Toutes les instances de dnsmasq en cours d'exécution doivent être redémarrées. Le moyen le plus simple est de redémarrer toutes les machines sur lesquelles dnsmasq opère, y compris les hôtes et invités de virtualisation. Comme les instances dnsmasq peuvent être exécutées par libvirt et d'autres composants du système, il est nécessaire de redémarrer ces composants. Le redémarrage de ces instances sans nouvel amorçage de la machine nécessite des procédures différentes pour les différents composants. Par exemple, tous les réseaux libvirt utilisant dnsmasq doivent être redémarrés et rattachés aux machines virtuelles respectives. Il s'agit d'une procédure potentiellement compliquée, qui peut interrompre la production, et qui doit être adaptée et testée séparément pour chaque environnement.

Q: Dois-je appliquer les mesures d'atténuation ou mettre à jour si le paquet dnsmasq est installé sur mon système mais qu'il n'est pas en cours d'exécution (ou activé) ?

A: Si le paquet dnsmasq est installé sur votre système, vous risquez d'être vulnérable ou de devenir vulnérable à ces failles si dnsmasq est activé plus tard. Nous vous suggérons d'appliquer les mesures de mitigation expliquées dans la section relative et vous recommandons de mettre à jour le paquet dnsmasq dès que possible.

Remerciements

Red Hat remercie Moshe Kol et Shlomi Oberman (JSOF) pour avoir signalé cette vulnérabilité.

Références

Article de recherche JSOF sur DNSpooq

Comment utiliser le GPG pour vérifier le contenu signé de la Sécurité produits