Le CERT publie des CVE pour six vulnérabilités critiques de sécurité dans dnsmasq
(lists.thekelleys.org.uk)- Le CERT a publié le 11 mai 2026 un ensemble de CVE concernant six vulnérabilités critiques de sécurité dans dnsmasq
- Ces vulnérabilités sont toutes d’anciens bugs et affectent presque toutes les versions de dnsmasq, à l’exception de quelques versions très anciennes
- Les CVE ont été divulguées à l’avance aux éditeurs, et chaque éditeur doit distribuer à temps une version corrigée du paquet dnsmasq
- 2.92rel2, qui applique les correctifs à la version stable dnsmasq 2.92, a été publiée et peut être téléchargée depuis l’emplacement habituel
- Le tag dnsmasq-2.93rc1 doit être créé prochainement, avec pour objectif une sortie de la version 2.93 d’ici environ une semaine après les tests
Divulgation des vulnérabilités dnsmasq et correctifs
- Le CERT a publié le 11 mai 2026 un ensemble de CVE concernant six vulnérabilités critiques dans dnsmasq
- Ces vulnérabilités sont toutes d’anciens bugs et concernent presque toutes les versions de dnsmasq, à l’exception de quelques versions très anciennes
- Les CVE ont été divulguées à l’avance aux éditeurs, et chaque éditeur doit distribuer à temps une version corrigée du paquet dnsmasq
- Les détails et les correctifs sont disponibles sur https://thekelleys.org.uk/dnsmasq/CVE/
- 2.92rel2, qui applique les correctifs à la version stable dnsmasq 2.92, a été publiée et peut être téléchargée depuis l’emplacement habituel
- Les commits de correction seront également intégrés à l’arbre de développement au même moment ; certains utilisent les mêmes correctifs que les backports, tandis que d’autres constituent une réécriture plus complète traitant la cause racine
Hausse des rapports pilotés par l’IA et plan pour la 2.93
- Au cours des derniers mois, les recherches de sécurité basées sur l’IA ont fortement augmenté le nombre de rapports de bugs, et la déduplication ainsi que leur classification ont demandé beaucoup de temps
- Les bugs ont été répartis entre ceux nécessitant une divulgation préalable aux éditeurs et ceux qu’il vaut mieux corriger immédiatement après publication ; cette distinction est inévitablement subjective
- Puisque plusieurs “good guys” ont trouvé à répétition les mêmes bugs, il est probable que les “bad guys” aient également pu les trouver, ce qui réduit fortement l’intérêt d’un long embargo
- La coordination de l’embargo et la fourniture de backports demandent beaucoup de temps et d’efforts à tous les participants
- Pour la plupart des bugs, la priorité est de les corriger dans les prochaines versions afin de publier une nouvelle version de dnsmasq avec le moins de bugs possible
- Les nombreux commits de sécurité ajoutés au dépôt git dans les semaines précédant l’annonce vont dans le même sens
- Le tag dnsmasq-2.93rc1 doit être créé prochainement, avec pour objectif de publier la version stable 2.93 aussi vite que possible
- Les tests de la release candidate sont importants ; les utilisateurs qui le peuvent sont donc encouragés à tester rapidement
- Si tout se passe bien, 2.93 pourrait sortir dans environ une semaine
- Le “tsunami” de rapports de bugs générés par l’IA ne montre aucun signe de ralentissement, si bien que le même processus pourrait bientôt se répéter
- Il existe une tension entre l’intégration d’un maximum de bugs en cours de traitement dans la 2.93 et une sortie dans les délais, la priorité allant à une publication rapide
1 commentaires
Commentaires sur Hacker News
On a l’impression qu’on arrive à un point où il devient urgent de réécrire le code écrit en C dans des langages sûrs pour la mémoire
La plupart des vulnérabilités découvertes récemment sont directement liées à des langages non sûrs pour la mémoire, et il semble très difficile de justifier qu’on ne puisse pas écrire des serveurs DNS/DHCP en Rust ou en Go, si possible sans
unsafeLes chercheurs en sécurité IA font au moins quelque chose. Si réécrire tout en Rust était si simple, on aurait dû voir arriver un remplaçant Rust solide dès le lendemain de ce genre d’incident
Si ce n’est pas le cas, c’est parce qu’on gagne difficilement des étoiles GitHub avec ce type de travail
Je doute que « on ne connaît pas la taille maximale donc tout doit être dynamique » soit vraiment la bonne approche. Qu’un programme déclare une taille maximale acceptable pour les entrées, puis renvoie une erreur au-delà ou utilise un buffer circulaire, ce n’est pas la fin du monde
Si l’on connaît la taille, on peut concevoir en conséquence. La RAM est finie, et il est étrange que toutes les couches construites dessus soient conçues comme si elle était infinie
Passer à Rust semble être une perte de temps énorme, et cela ne règle pas le problème fondamental : l’incapacité à modéliser les programmes selon la réalité de ressources système finies. Ce n’est d’ailleurs pas qu’un problème de mémoire. Le cas de Chrome qui déploie un modèle de 4 Go sur l’appareil de l’utilisateur relève de la même logique
https://xchglabs.com/blog/dnsmasq-five-cves.html
Je me demandais si OpenWRT avait publié une nouvelle build ; la réponse est non pour l’instant, mais c’est en cours
https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...
https://github.com/mirror/dd-wrt/issues/465
https://svn.dd-wrt.com/changeset/64944
https://svn.dd-wrt.com/changeset/64905
La publication est annoncée comme « coming soon »
Mon MaraDNS a été audité de façon assez approfondie avec l’arrivée de l’ère des audits de sécurité assistés par IA
Depuis 2023, aucun bug de sécurité sérieux n’a été découvert [1]
Tout ce que les auditeurs ont trouvé, c’est soit « Deadwood met plus de temps que d’habitude à libérer les ressources quand il reçoit un paquet inhabituel en mode totalement récursif » [2], soit « un utilitaire auxiliaire inclus dans MaraDNS, qui ne compile même plus depuis 2022, a un buffer overflow uniquement quand
$HOMEdépasse 50 caractères » [3]Je suis personnellement très satisfait du fait que MaraDNS semble assez sûr maintenant qu’il fait l’objet de véritables audits de sécurité approfondis
[1] https://samboy.github.io/MaraDNS/webpage/security.html
[2] https://github.com/samboy/MaraDNS/discussions/136
[3] https://github.com/samboy/MaraDNS/pull/137
Lua non plus n’a pas été exempt de correctifs de sécurité
J’ai moi aussi quelques bibliothèques que j’ai écrites, et aucun bug de sécurité sérieux n’y a été découvert depuis 1991. Bien sûr, personne n’utilise mes bibliothèques
Ce n’est pas pour minimiser l’accomplissement, mais il est important de replacer ce genre d’affirmation dans le contexte de la base d’utilisateurs
Cette auto-promotion apporte très peu de valeur à la discussion sur dnsmasq
Plus un logiciel est utilisé, plus il est examiné, et plus on découvre de bugs et de cas limites
Heureusement que ce logiciel n’est pas utilisé dans des millions d’appareils qui ne reçoivent pratiquement jamais de mises à jour
C’est assez grave
« Un attaquant distant capable d’effectuer des requêtes DNS ou de fournir des réponses DNS peut provoquer une importante écriture hors limites sur le tas »
Une réponse DNS malformée peut « déclencher une boucle infinie qui empêche dnsmasq de répondre à toute requête »
Des requêtes DHCP malveillantes peuvent provoquer un buffer overflow
Le tsunami de rapports de bugs IA n’existe pas sur tous les projets. Comme dit plus haut, MaraDNS n’en a pas eu
Je pense que djbdns et tinydns n’en auraient pas eu non plus. Si c’était le cas, cela aurait été largement signalé
Je n’ai jamais vraiment compris pourquoi certains projets deviennent extrêmement populaires et d’autres non
On a presque l’impression que des outils « trop dangereux pour être publiés » scannent tous les projets, mais ne contactent sélectivement que ceux qui ont des problèmes. Ainsi, ils n’ont pas à reconnaître que leur outil n’a rien trouvé
Je n’ai jamais aimé utiliser dnsmasq. J’ai toujours eu l’impression qu’il mettait trop de choses dans un seul outil
J’ai toujours préféré configurer séparément un résolveur cache local, un serveur DHCP et la configuration de boot TFTP/PXE
Par exemple, envoyer les requêtes
*.example.comvers un serveur amont précis, renvoyer NXDOMAIN pour des sites de phishing, ou ajouter toutes les IP résolues depuis*.example.orgà unipsetpour du routage par politiqueCette dernière fonctionnalité marche sur FreeBSD même si BSD n’a pas
ipset, et les listes*.example_xyz.compeuvent être très volumineuses ; il paraît que dnsmasq les gère efficacement dans ses versions récentes10/10, aucun regret, je recommande
Par exemple, Opnsense utilise uniquement la partie DHCP de dnsmasq et unbound pour le DNS, et ça paraît un peu « bizarre »
DHCP et DNS sont liés, et PXE a besoin d’entrées DHCP. Pour une configuration simple, sinon, il faut assembler au moins trois démons avec chacun leur propre syntaxe de configuration
Question de débutant pour des gens plus expérimentés dans ce domaine : pourquoi les logiciels de cet espace ne sont-ils pas davantage écrits sur des runtimes de langages comme Erlang, avec garbage collection et concurrence ?
La perte de performance était trop importante, il y avait un runtime opaque dont il était difficile de savoir à quel point il était stable à l’époque, peu de contributeurs, et une empreinte de dépendances importante car il n’était pas installé sur la plupart des systèmes
Même quand j’ai utilisé Erlang sur des systèmes de production vers 2015, il y avait encore des angles morts dès qu’on s’écartait un peu du cas d’usage prévu. Ce n’est pas une critique propre à Erlang ; beaucoup de langages et de runtimes étaient dans le même cas
Une bonne partie des systèmes qui vont continuer à se faire malmener dans les semaines ou les mois à venir ont un historique similaire. Pour le noyau Linux, la seule alternative potentielle de l’époque était à peu près le C++. OpenSSL, classique des problèmes de sécurité, a commencé en 1998
Je suis moi aussi tout à fait d’accord avec l’idée qu’« il ne faut pas écrire de nouveaux projets exposés au réseau en C », mais si l’on retourne en 1998, il est difficile de dire quelle autre option aurait été réaliste
Des langages plus sûrs existaient, mais avec des communautés bien plus petites que celle du C, et il était beaucoup plus difficile d’avoir des garanties sur leur stabilité. Java existait déjà, mais je ne sais pas à quel moment précis il est devenu un candidat sérieux pour les serveurs réseau ; j’aurais tendance à dire vers la fin des années 2000. Ce que j’ai vu de Java en 1999 n’en était pas encore là
Par exemple, en 2011, j’exploitais un serveur réseau en Haskell pour un usage relativement peu critique, et il tombait dans des conditions qui n’avaient rien d’extrême pour un réseau de production. En 2013, j’ai réutilisé la même base de code sans changer la boucle d’exécution centrale, et c’était amélioré d’environ 90 %, donc j’en ai conclu que le problème venait plutôt de Haskell que de mon code
Ce n’était toujours pas au point d’aller en vraie production, mais au moins cela montrait que mon code n’était pas la cause de l’échec. Autrement dit, même si Haskell existait dans les années 2000, il aurait été difficile d’en faire un choix réaliste pour des serveurs réseau à cette époque
Aujourd’hui, il y a bien plus d’options qu’avant
structsur un paquet réseau, ce qui est assez simpleDans d’autres langages, ce n’est souvent pas aussi direct
Et bien sûr, c’est aussi plus lent et plus volumineux