Faille de conception du systême DNS

Pause Café
#1

Bonjour,
ce matin, j’ai entendu une vague news comme quoi la conception du systême dns avait une faille qui permettait de faire du phishing par empoisonnement (un classique somme toute). La particularité de cette faille est qu’elle ne dépenda pas de l’OS. M$, Cisco, Juniper et Sun ont donc bossé ensemble pour trouver un patch, >sans diffuser d’info sur la faille elle même<.
Une question que je me pose et dont je n’ai pas trouvé la réponse: est ce qu’ils ont donné les infos suffisantes aux développeurs de dns tournant sous linux pour qu’ils corrigent eux aussi la faille ?

infos:
afp.google.com/article/ALeqM5iH2 … v2iXbU3oqg
internetnews.com/security/ar … soning.htm

#2

it.slashdot.org/article.pl?sid=08/07/08/195225

#3

Cela aurait avoir avec ceci ?

debian.org/security/2008/dsa-1603

#4

Oui, c’est ça…

#5

Enorme trou de sécurité découvert dans tous les serveurs DNS.

J’avais lu l’info en diagonale hier sur /. mais je ne me suis pas rendu compte directement de sa portée. En mars, Dan Kaminsky, un spécialiste en sécurité, travaillait sur tout autre chose quand il a découvert par hasard une faille de “design” du système DNS qui permettrait à n’importe qui de se faire passer pour n’importe quoi! Le phishing absolu et imparable. Faille de design qui touche toutes les plateformes.

Un groupe de travail multi-constructeurs, multi-systèmes s’est réuni d’urgence et en secret en mars à Redmond chez MS pour réfléchir à la parade. Le patch vient de sortir discrètement sur tous les systèmes.

Sur son blog, Dan Kaminsky encense DJB Berntein, celui-là même qui a offert une récompense à celui qui trouvait une faille à son appli DNS djbdns.
cr.yp.to/djbdns/guarantee.html

[quote]DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.
doxpara.com/[/quote]

01net.com/editorial/385935/u … -internet/
news.bbc.co.uk/2/hi/technology/7496735.stm

#6

:smt006

viewtopic.php?f=1&t=15103
:smt103

#7

Effectivement. Double emploi. Un modo pour fusionner?

En passant vous pouvez tester votre serveur DNS pour vérifier s’il est patché. Le test se trouve sur le blog de Dan Kaminsky.
doxpara.com/

#8

Aprés prise de renseignement auprés de mon developpeur flamand (celui qui a failli être DPL), les gars de bind ont été informés tout de suite, mais l’info n’est remontée aux empaqueteurs debian qu’une fois le pb corrigé dans bind, le 08/07/08.
Enfin bon, c’est pas encore corrigé en sid, mais pour vos serveurs en etch, s’ils sont à jour des paquets de sécurité, ils sont protègés… C’est ça la stable !

#9

[quote=“ripat”]Effectivement. Double emploi. Un modo pour fusionner?(…)[/quote]fait.

#10

[quote=“ziouplaboum”]http://it.slashdot.org/article.pl?sid=08/07/08/195225

[quote]“The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn’t directly possible.”[/quote][/quote]Ca m’étonnerait que le reverse engineering soit impossible en regardant les sources de bind… Encore un qui croit qu’il est protègé par du propriétaire “parcequ’on ne peut pas regarder dedans”. Il sera le premier surpris quand un type aura trouvé une exploit dans son joli soft propriétaire bien opaque et lui aura vidé son compte par phishing…
C’est tout ce qu’il mérite tiens… :laughing:

#11

J’ai peut être dit une bêtise, il semble que le correctif de debian concerne le client host afin de lui mettre un alea dans les ports utilisés: les requêtes se font par UDP, quelqu’un qui connait les ports peut répondre avant le serveur DNS et donc fournir une réponse erronée. Ça n’a pas l’air d’être le bug dont on parle partout en ce moment qui est une corruption du cache DNS (si j’ai bien compris).

#12

En fait si, d’après la DUF ce serait ça. Ce sont bien les cache des DNS qui peuvent être falsifiés, c’est donc non les DNS de domaine mais les DNS servant des personnes qui sont fragilisés. Je suis en train de faire un backport du bind9 sécurisé de etch vers sarge…

#13

Voilà la faille de base, mais il y a deux autres alertes concernant le pb:
debian.org/security/2008/dsa-1603

#14

[quote=“fran.b”]Je suis en train de faire un backport du bind9 sécurisé de etch vers sarge…[/quote]il n’y a pas ou il n’y aura pas de correction pour sarge ?

#15

Ça fait plus d’un an que Etch est sortie, donc il n’y a pas de correctif “officiel”, soit tu upgrade, soit tu te fait ton backport, soit tu fait suffisament confiance à quelqu’un pour le faire.

Au passage c’est quand même la deuxième grosse faille en peu de temps, la première étant la faille open-ssl de Debian :confused: , cette fois le tarif est le même pour tout le monde mais quand même ça fait beaucoup en peu de temps je trouve.

#16

Ah ben pour les pb d’openssl, j’ai cru comprendre que le responsable debian qui a laissé passer ça continue à se faire incendier par les autres responsables debian. Mais c’est vrai que quand on est responsable d’un outil de sécurité, introduire une faille, c’est un peu la honte.

Pour la faille dans le dns, bon, ben c’est la faute à pas de chance: vu le temps qu’il a fallu pour que la faille se voie, on ne peut pas reprocher à l’équipe qui a défini la norme de ne pas avoir vu ça tout de suite.

#17

[quote=“mattotop”]Ah ben pour les pb d’openssl, j’ai cru comprendre que le responsable debian qui a laissé passer ça continue à se faire incendier par les autres responsables debian. Mais c’est vrai que quand on est responsable d’un outil de sécurité, introduire une faille, c’est un peu la honte.
[/quote]De ce que j’ai pu en lire dans MISC, la faille est la aussi loin d’être évidente et, selon la conclusion de l’auteur de l’article, la source du problème viendrait plutot de la lisibité du code d’open-ssl.J’avais pu lire sur ce forum que certains trouvaient bizarre des attaques type bruteforce sur leur connexion ssh…Je n’ose pas imaginer les conséquences si certaines personnes ont vu la faille avant tout le monde et l’aurait exploitée :confused:

[quote=“mattotop”]Pour la faille dans le dns, bon, ben c’est la faute à pas de chance: vu le temps qu’il a fallu pour que la faille se voie, on ne peut pas reprocher à l’équipe qui a défini la norme de ne pas avoir vu ça tout de suite.[/quote]Tout à fait d’accord mais encore une fois ça fait vraiment longtemps (depuis 1983) et encore une fois je n’ose pas imaginer ce qu’auraient pu faire des personnes mal-intentionnées avec cette faille au bout des doigts : on pourrait presque dire qu’il étaient (sont encore?) les maîtres du monde :confused:

#18

Le support de sécurité de srge a terminé en Février 2008. Le problème est que bind par défaut sur sarge est la version 8… Il y a donc un changement majeur à faire. Un peu rude à faire en remote: * mise à jour en etch ou mise à jour en bind9. Va falloir tester ça… Le backport est fait sur
deb boisson.homeip.net/debian sarge divers
mais pour une installation native, il y a d’autres paquets à backporter.

#19

slt,

Une belle explication du problème lié au protocole DNS et non au os, ios.

sid.rstack.org/blog/index.php/283-dns-dns-dns

oops j’oubliais une belle conversation des opérateurs français à ce sujet.

mail-archive.com/frnog@frnog … 03095.html

#20

En suivant ton lien j’ai trouvé ce commentaire sur DJB:

[quote]Le serveurs DNS DJBDNS de Dan Bernstein (l’auteur de qmail), ainsi que PowerDNS de Bert Huber, par exemple, ne sont pas vulnérables, car depuis très longtemps ils veillent à choisir des ports source aléatoires et se veulent sécurisés, quoi qu’on en dise ou qu’on en pense.
bruno.kerouanton.net/blog/2008/0 … z-vos-dns/[/quote]

Ce DJB m’épate. Il a tout compris avant tout le monde. Un poil sûr de lui avec sa promesse de récompense à qui trouve une faille à DJBDNS. Mais il est respecté par ses pairs et admiré par les autres.

Ce que je ne comprends pas , c’est pourquoi son DJBDNS n’est pas plus utilisé par les grands ISP. Il a pourtant la réputation d’être plus facile à configurer que Bind non?

Un script perl pour tester votre serveur DNS
bortzmeyer.org/files/noclicky-1.00.pl

Mon ISP (belgacom) vient de patcher ce matin.