Vulnérabilité de type DoS sur BIND 9

Posté par saad le 06 juin 2002 à 10:15. Modéré par Benoît Sibaud.

Étiquettes :

juin

2002

Une vulnérabilité de type DoS (déni de service) a été découverte sur BIND 9. L'exploitation de cette vulnérabilité se fait grâce à la construction d'un paquet malformé qui aura pour effet d'arrêter le service BIND. L'impact d'une telle attaque peut être grave dans la mesure où beaucoup de services importants tels que la messagerie dépendent du DNS pour fonctionner correctement.

Il est recommandé de mettre à jour BIND à la version 9.2.1. Il est à noter que les versions 8 et 4 ne sont pas concernées par cette vulnérabilité.

Aller plus loin

Avis du CERT (7 clics)

# Vérifier la version de bind utilisée

Posté par Lucas le 06 juin 2002 à 10:44. Évalué à 10.

Après les 1574572187 graves trous de sécurité de Bind 8, voila Bind 9 qui rentre donc dans la partie ...

Pour vérifier rapidement quelle version de Bind on utilise :
$ host -t txt -c chaos version.bind localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:

version.bind text "9.2.0"

Hop au boulot :O)
- [^] # Re: Vérifier la version de bind utilisée
  
  Posté par Sébastien Koechlin le 06 juin 2002 à 11:39. Évalué à 10.
  
  Si j'ai bien compris, en fait, bind9 est un peu sensible; lorsqu'il trouve que quelque chose ne va pas bien, comme par exemple une attaque, ou une requête d'un windowsXP, il se suicide afin d'éviter d'exposer un trou de sécurité.
  
  Comme ça a été prévu ainsi, en fait, une nouvelle instance de named doit être relancé immédiatement par le système, il n'y a donc pas coupure du service.
  
  Cette méthode, franchement sale, ne règle pas le problème, si un petit plaisantin s'amuse à envoyer des paquets considéré comme hostiles en permanence, le service est effectivement très perturbé par les re-démarrage continuels du démon.
  
  Vous pouvez lire à ce sujet un excellent mail de notre ami D. J. Bernstein, homme particulièrement peu modeste, bon programmateur, auteur de maraDNS à la license discutable, qui fait une bonne analyse du comportement de Bind9 :
  
  http://online.securityfocus.com/archive/1/249245/2002-04-29/2002-05(...)
  - [^] # Correction
    
    Posté par Sébastien Koechlin le 06 juin 2002 à 11:47. Évalué à 10.
    
    Vous aurez corrigé de vous même, mais :
    
    D. J. Bernstein est l'auteur de djbdns contrairement à ce que j'ai écris il y a quelques minutes, à la license discutable.
    
    http://cr.yp.to/djbdns.html(...)
    
    MaraDNS est un autre serveur DNS, alternative intéressante à Bind9, dans le domaine public.
    
    http://www.maradns.org/(...)
  - [^] # Re: Vérifier la version de bind utilisée
    
    Posté par Gyro Gearllose le 06 juin 2002 à 11:51. Évalué à 10.
    
    <mode humour=on>
    homme particulièrement peu modeste, bon programmateur,...
    Programmateur de quoi ? De sèche linge, de machine à laver ou de four ? Ne serait-ce pas plutôt programmeur ? En tout cas, j'm'en fous, j'le connais pas
    </mode humour=off>
    
    Bon, à part ça, c'est vrai que cette histoire de 'si on m'emm...', j'me met en carafe, et j'attend qu'on me relance proprement, ça ne résoud pas les problèmes. Si la politique de l'autruche était si efficace, tout le monde l'utiliserait...Si j'ai l'temps, j'vais même coder un serveur qui se plantera dès qu'on tentera une connection... Comme ça, que les demandes soient bonnes ou pas, y'aura pas de trous de sécurités !
    - [^] # Re: Vérifier la version de bind utilisée
      
      Posté par Dugland Bob le 06 juin 2002 à 12:26. Évalué à -5.
      
      Plus important : programmateur mécanique ou programmateur électronique car si c'est mécanique y'a de l'usure et faut le changer de temps en temps.
      Ceci dit si c'est un bon programmateur ça doit être un électronique car ils ne dérivent pas dans la temps et sont plus précis
      
      Ca me fait penser qu'il va falloir que je change le chapeau de ma page web, il commence à être ancien.
    - [^] # Re: Vérifier la version de bind utilisée
      
      Posté par quad le 06 juin 2002 à 12:26. Évalué à 10.
      
      Je suis plus nuancé sur le sujet : je pense qu'il y a des situations ou un hara-kiri est préférable.
      
      Pour des alertes virales majeures par exemple, et en attendant
      la nouvelle "table de signatures", on peut choisir de fermer le rideau.
      
      On en revient toujours à l'éternel dilemme :
      
      - choisir de mettre en prod une application que l'on sait pas suffisamment sécurisée
      - ne pas mettre en prod cette appli et perdre de l'argent
      
      Tout est question de RMT (Risque Maximum Tolérable)
      - [^] # Re: Vérifier la version de bind utilisée
        
        Posté par Gyro Gearllose le 06 juin 2002 à 13:47. Évalué à 8.
        
        Pour des alertes virales majeures par exemple, et en attendant
        la nouvelle "table de signatures", on peut choisir de fermer le rideau.
        
        Je suis un peu d'accord avec toi... Dans le cas cité ci-dessus, oui, y'a pas photo.
        Mais dans le cas d'un serveur DNS, je ne vois pas l'intérêt d'un hara-kiri.
        Pourquoi ne pas simplement ignorer les demandes quand celles-ci sont trop nombreuses ou douteuses ?
        J'ai pas lu les sources de bind, mais je suis pratiquement certain qu'il doit quelque part y avoir un genre de switch () case : break; dans le code pour choisir ce qu'il faut faire selon la requête utilisateur. Si c'est effectivement le cas, qu'est-ce qui empêche de mettre une clause default qui ne fait rien ? De plus, le nombre de requêtes à traiter simultanément devrait (pourrait) être limité, ce qui ferait que si le serveur st trop chargé, il ne répond pas aux demandes. A la limite, ça pourrait même être géré avec une file d'attente dont la taille serait paramétrablé. En codant ainsi, je ne crois pas qu'on puisse surcharger le serveur.... Ou alors j'ai de sacrées lacunes en algo et tout ce qui va avec.
        
        Quoi qu'il en soit, en ce qui concerne le RMT tu as totalement raison. [++]
- [^] # Re: Vérifier la version de bind utilisée
  
  Posté par moulator le 06 juin 2002 à 18:51. Évalué à 9.
  
  Heu, chez les admin. parano comme moi, ta commande ne renvoie d'une blague du genre version.bind text "A good one".
  En effet, je laisse pas visibles les numéros de version des services tournant sur mes serveurs (c'est toujours ça de plus à chercher si un petit con veut exploiter une faille).
  En revanche, un simple "named -v" renvoie le numéro de version du démon, pour peu que l'on soit loggé (en SSH, bien sûr !) sur la machine.
# messagerie ?

Posté par PLuG le 06 juin 2002 à 10:49. Évalué à 10.

beaucoup de services importants tels que la messagerie dépendent du DNS

heuuu c'est bizarre cette phrase. Qui utilise des services en configurant l'adresse IP directement ???

la messagerie utilise le DNS, certes, mais http,ftp,ntp,irc,ssh... en fait TOUS les services reposent sur DNS.
En clair si on fait tomber les serveurs DNS c'est tout Internet qui en souffre (et pas seulement le mail)
- [^] # Re: messagerie ?
  
  Posté par zeiram le 06 juin 2002 à 12:33. Évalué à 10.
  
  Ce qu'entendait (probablement, je ne suis pas dans sa tête) l'auteur de la news par sa phrase :
  
  beaucoup de services importants tels que la messagerie dépendent du DNS
  
  doit se référer aux enregistrements MX du DNS. Ces enregistrements indiquent quels sont les serveurs qui doivent traiter les emails à destination d'un domaine. Les serveurs DNS font donc beaucoup plus de travail que la "simple" resolution nom -> IP pour ce qui touche à la messagerie.
  
  De plus, la résolution nom -> IP peut être cachée par d'autres serveurs DNS plus proches de l'utilisateur, ou même par un fichier hosts directement chez l'utilisateur (et on peut donc parfois se passer complètement d'un accès au serveur DNS du domaine pour résoudre le nom vers l'IP). Par contre, ces opérations de cache et le fichier hosts ne fonctionnent pas pour ce qui est des enregistrements MX. Donc un serveur DNS d'un domaine qui ne répond bloque complètement la messagerie du domaine, sans possibilité de contourner le problème (à l'exception, bien sûr, de l'utilisation de serveurs de noms secondaires, tertiaires, ...).
  
  Zeiram
  - [^] # Re: messagerie ?
    
    Posté par PLuG le 06 juin 2002 à 13:08. Évalué à 10.
    
    Tiens ?
    Je ne savais pas que les reponses aux requetes MX n'etaient pas mises en cache.
    
    D'ailleur je viens de sniffer sur un dns ici, et apparemment il repond aux requetes MX en se basant sur son cache (vu qu'il me repond et qu'il ne pose la question a aucune autre machine) ...
    
    Peux-tu nous indiquer tes sources ??
    A moins que cela vienne de mon bind (9.2.1 evidement).
# Petite histoire de Bind

Posté par j le 06 juin 2002 à 12:41. Évalué à -2.

http://cr.yp.to/djbdns/bugtraq/20010201072942-22539-qmail@cr-yp-to(...)
- [^] # Re: Petite histoire de Bind
  
  Posté par Lucas le 06 juin 2002 à 13:25. Évalué à 10.
  
  C'est pas une histoire, c'est de la pub pour son serveur DNS qui n'est pas libre.
  
  Si son soft était distribué sous une licence comparable à celle de Bind, il pourrait peut-être la ramener.
  
  En attendant, OpenBSD a Bind 4 dans l'installation par défaut. Peut-être que pour les serveurs DNS sont un domaine dans lequel il vaut mieux ne pas chercher à suivre la mode !
  - [^] # Re: Petite histoire de Bind
    
    Posté par Éric (site web personnel) le 06 juin 2002 à 15:13. Évalué à 4.
    
    C'est quoi la licence de djbdns ?
    J'ai cherché sur le site mais pas trouvé (meme dans la FAQ), la seule chose que j'ai trouvé est qu'il le dit "free" ce qui veut tout est rien dire hors contexte...
    - [^] # Re: Petite histoire de Bind
      
      Posté par j le 06 juin 2002 à 15:59. Évalué à 10.
      
      DJB est a mon avis l'une des rares personnes a pouvoir se permettre de "se la ramener". Quand il critique quelque chose, ce n'est pas gratuit. Il demontre toujours ce qu'il affirme. Que ce soit en securite, en optimisation ou en maths, DJB calme pas mal de monde.
      
      Concernant la license de DjbDNS comme pour celle de QMail, le principe est le suivant :
      - Les sources sont disponibles et librements redistribuables sans modification.
      - On peut aussi creer des binaires a partir des sources d'origine et les distribuer librement.
      - _Mais_ il est interdit de diffuser des binaires crees a partir de sources trafiques sans l'autorisation de l'auteur. Il est aussi interdit de diffuser des sources modifies sans autorisation.
      
      Voila pourquoi certains reprochent a Qmail et DjbDNS de ne pas etre "libres".
      
      Neanmoins, cette license n'est pas idiote.
      
      Imagine que je prenne DjbDNS, que j'ajoute des fonctions et que j'en distribue des RPM. 2 mois plus tard, un gros trou de securite est trouve dans ces RPM. Tout le monde va dire "putain DjbDNS c'est de la merde, y a un root exploit dedans!". Pourtant, ce n'est pas vrai. La version d'origine etait clean.
      
      Si je veux distribuer DjbDNS avec des modifs, la license m'oblige a distribuer :
      - Le source original.
      - Les patches que j'y ajoute.
      Et pas de package binaire. Comme ca, on sait exactement ce qu'on installe. On sait explicitement quelles modifications ont ete apportees.
      
      DJB donne des sous a quiconque arrivera a trouver le moindre trou de securite dans ses softs. Jusqu'a present, personne n'en a trouve. Le fait que chacun ne vienne pas mettre son grain de sel dans le code source sans son approbation y est pour beaucoup.
      
      La license est particuliere. Ce n'est pas "libre" comme la license BSD. Mais ca ne signifie pas que les softs sont inutilisables ou que l'on cache quoi que ce soit. Au contraire.
      - [^] # Re: Petite histoire de Bind
        
        Posté par Foxy (site web personnel) le 06 juin 2002 à 17:05. Évalué à 10.
        
        "Que ce soit en securite, en optimisation ou en maths, DJB calme pas mal de monde."
        
        C'est vrai que DJB a des connaissances très pointues (voir les discussions à n'en plus finir que suscite son dernier article de crypto sur les clés de 1024 bits) et que son code est de qualité.
        Mais on peut quand même lui faire pas mal de critiques :
        - il est très egocentrique et peu ouvert aux critiques et à la discussion
        - pour son code Unix, il réinvente la roue car selon lui, tout ce qui a été fait "c'est de la merde mal codée" (qmail/sendmail, tcpserver/inetd, daemontools/syslog, djbdns/bind...)
        
        "_Mais_ il est interdit de diffuser des binaires crees a partir de sources trafiques sans l'autorisation de l'auteur. Il est aussi interdit de diffuser des sources modifies sans autorisation."
        
        J'ai beaucoup travaillé avec Qmail et ses outils connexes, et cette contrainte est vraiment chiante. Les sources de Qmail (v1.03) n'ont pas changées depuis 1998, néanmoins il existe des 10aines de patchs très utiles pour Qmail mais "monsieur DJB" estime qu'il ne faut pas les intégrer. De nombreux spécialistes de Qmail (Russell Nelson par ex.) apprécie très peu ce comportement (voir la ML de Qmail pour s'en faire une idée).
        
        D'autre part, il y a encore plus de contraintes que cela dans sa "pseudo" license : si on livre un binaire de Qmail, il doit obligatoirement être installé dans /var/qmail et nul part ailleurs ??? Complétement idiot de vérouiller ce point qui n'a aucune utilité.
        
        Mais je reconnais que son travail sur Unix est très bon en qualité de code et performant, une fois qu'on a fait l'effort de mettre les mains dedans (c'est un peu un plat de spaghettis au départ qmail --> tcpserver --> daemontools --> ...)
        
        [^] # Re: Petite histoire de Bind
        
        Posté par j le 06 juin 2002 à 19:25. Évalué à 9.
        
        Il y a des patches et des outils tres utiles. Mais il y a par exemple eu un root exploit sur deux d'entre eux (une variante de checkpassword et un truc de SSL) .
        
        La derniere version de Qmail est effectivement sortie en 98. Pourtant, elle est toujours tres utilisee, car il n'y a toujours pas de gros bogue ou de faille de securite en vue. En dehors de Qmail, y a-t-il beaucoup de softs que vous feriez tourner depuis 4 ans sans le moindre upgrade?
        
        La contrainte des repertoires d'installation est un peu hors normes (/var/qmail, /packages, ...) . Et c'est en grande partie a cause de ca que DJB s'est fait expulser d'OpenBSD. Mais bon, rien ne t'empeche de creer des liens dans /usr/local/bin, ou de monter les repertoires.
        
        ucspi-tcp et daemontools sont des packages tres utiles, et au contraire pas spaghettis du tout dans la mesure ou un programme fait une chose bien precise et rien d'autre. Perso ce sont les premiers trucs que j'installe sur une nouvelle machine.
# update de &é"'(-è_ç !!!!

Posté par jerdent (site web personnel) le 06 juin 2002 à 18:40. Évalué à 0.
- 1 serveur sous debian woody: quelques secondes pour mettre à jour par apt-get
- 2 serveurs sous redhat 7.1: je galere encore a recompiler le src.rpm (car le binaire passe pas evidemment)... à la toute fin du make:
```
/bin/sh /usr/src/redhat/BUILD/bind-9.2.1/libtool /usr/bin/install -c -m 644 libisc.la /var/tmp/bind-root/usr/lib

libtool: ltconfig version `' does not match ltmain.sh version `1.3.5'

Fatal configuration error.  See the libtool docs for more information.
```
Mais quelle merde cette redhat !!!!
- [^] # Re: update de &é"'(-è_ç !!!!
  
  Posté par Gyro Gearllose le 07 juin 2002 à 08:51. Évalué à 0.
  
  C'est là qu'on voit toute la puissance d'un LFS !
  Mise à jour d'hier : j'ai récupéré le config.status de l'ancienne version dans le rep des sources de la dernière (celle qui est corrigée), je l'ai lancé, puis un simple make && make install et hop, installé, configuré et tout et tout !
  Plus qu'à faire /etc/rc.d/init.d/named restart et le tour est joué, on n'en parle plus.
  En parlant de redhat, y'a même pas la version 8.12.4 de sendmail qui est dispo. Ils en sont à la version 8.11.??? qui ne fonctionne pas comme je voudrais. Et comme c'est un serveur de production sur lequel je n'ai pas le droit d'installer à partir des sources, j'suis bien dégouté !
  T'as bien raison, RedHat, c'est d'la daube en boite !
- [^] # Re: update de &é"'(-è_ç !!!!
  
  Posté par PLuG le 07 juin 2002 à 09:00. Évalué à 8.
  Je ne comprends pas ton probleme.
  regarde ma redhat:
```
#rpm -qa --last | head -3

bind-9.2.1-0.7x               mer 05 jun 2002 15:26:40 CEST

bind-utils-9.2.1-0.7x         mer 05 jun 2002 15:26:19 CEST

tcpdump-3.6.2-11.7.2.0        ven 31 mai 2002 10:38:00 CEST
```
  mon bind, je l'ai upgradé la veille de la news sur linuxfr ...
  
  la meilleure distribution, c'est celle que TU connais. Mais c'est pas la peine de baver sur les autres.
  - [^] # Re: update de &é"'(-è_ç !!!!
    
    Posté par Gyro Gearllose le 07 juin 2002 à 19:12. Évalué à -3.
    
    Toutes mes excuses, j'ai oublié de préciser que nous utilisons la version 6.2 de RedHat, car les applications qui sont développées par nos sites de dev sont certifiées sur cette version.
    Je trouve juste dommage qu'avec ces versions, il faille attendre des plombes pour avoir un rpm, problème qui ne se pose pas avec un LFS. (pour mémoire, je ne suis pas arrivé à trouver un rpm de la dernière version de sendmail). Attention, je ne dénigre pas le travail que font les développeurs de redhat et consors, j'indique juste un point de vue personnel.
    En tout cas, je me colle allègrement un -1, car c'est relativement hors sujet !
    - [^] # Re: update de &é"'(-è_ç !!!!
      
      Posté par PLuG le 08 juin 2002 à 10:04. Évalué à 3.
      
      bon, effectivement, je ne fait tourner plus aucune redhat 6.2.
      
      Tes machines en redhat 6.2 sont elles en vue sur le reseau ? ont elles besoin de faire tourner bind ??
      Ou alors vous faites tourner des 6.2 de partout pour pas gerer plusieurs versions de la meme distrib ...
      
      Pour ce qui est du RPM de la derniere version de sendmail, j'ai eu le meme probleme. RedHat ne package pas de nouveau sendmail - c'est une decision qui leur appartient. J'ai donc pris un rpm source de mandrake (qui contient des specificités de mandrake et de nombreuses traces de RedHat aussi), je l'ai adapté a Redhat (7.2 mais je pense qu'il marche en 6.2), et je le fait tourner depuis plusieurs mois. [tout cela pour avoir la gestion STARTTLS interne a sendmail].
      Si tu veux je peux te fournir le .spec ou le rpm source carrement. Je ne pourrai le faire que lundi (au boulot).
      
      Pour ce qui est de bind sur 6.2, si le rpm source ne marche pas tel quel tu as 3 solutions:
      -attendre :-)
      -editer le .spec pour le faire marcher
      -prendre le .spec du rpm source du dernier bind disponible pour 6.2 et changer juste le tar.gz des sources (et les eventuels patchs).
      
      globalement, ce travail n'est pas tellement different d'un LFS, tout se passe dans le .spec ou il fautr modifier 3 lignes et relancer un "rpm -bb".
      
      repond dans ce thread pour me contacter je lis toujours les posts en reponse a mes commentaires.
      - [^] # Re: update de &é"'(-è_ç !!!!
        
        Posté par Gyro Gearllose le 08 juin 2002 à 13:29. Évalué à -1.
        
        Tes machines en redhat 6.2 sont elles en vue sur le reseau ? ont elles besoin de faire tourner bind ??
        Bon, passons en
        <mode 3615 mavie>
        Je travaille dans l'education nationale, et le ministère nous a doté il y a deux ans 1/2 maintenant d'un serveur netfinity d'IBM tournant sous RedHat 6.2. Les applis nationales sont développées sous informix, et sont validées sur cette version de RedHat.
        </mode>
        Sachant cela, nous ne pouvons pas faire de mise à jour vers une version 7.2 ou autre. Sinon, nos applis risquent de ne pas fonctionner. D'ailleurs, il nous a fallu oublier bash et zsh, car tout est validé sous ksh.
        
        Ce serveur nous sert à cela, mais aussi de squid, de nameserver, etc. Donc, oui, je crois bien qu'il va falloir que je mette à jour ma version de bind, mais je suis oligé d'attendre les directives venant de plus haut. Ceci dit, je ne pense pas être concerné, car nous sommes complétement injoignables de l'extérieur (réseau d'entreprise derrière plusieures barrières genre firewall, routeurs, murs anti-virus et tout le toutim).
        
        Pour ce qui est de sendmail, je te remercie de ton aide, mais j'ai trouvé comment le faire fonctionner pour qu'il réponde à mes besoins.
        
        En bref, et pour ne pas embêter tout le monde, je voulais que les boites locales soient automatiquement forwardées vers d'autres boites plus génériques (comme la mienne et deux ou trois autres). J'ai trouvé comment faire avec un sendmail.mc de 7 lignes et en mettant un .forward dansles homedirs des comptes concernés. Donc, pour l'instant, vu que j'ai résolu mon pb, je suis bien content.
        Merci encore.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.