Faille de conception du systême DNS

Pause Café
#21

DJB a raconté énormément de choses, parfois il est tombé juste, souvent il a dit d’énormes bêtises. Par exemple :

cr.yp.to/djbdns/dot-fr.html (faux de A à Z et dangereux)
cr.yp.to/djbdns/idn.html (Il n’a rien compris à Unicode)

Comme, en outre, il est imbittable, insupportable et qu’il insulte tout le temps ses contradicteurs, il est parfaitement normal qu’il soit ignoré par la majorité.

Parce que les administrateurs des grands ISP sont d’un niveau plus élevé que le lecteur de Slashdot et qu’ils ne croient pas sur parole les affirmations du genre « C’est plus convivial » ou bien « C’est plus secure » ?

Il existait déjà plusieurs résolveurs libres (contrairement au djbware) et standards (contrairement au djbware) qui n’avaient pas la vulnérabilité :

#22

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

mail-archive.com/frnog@frnog … 03095.html[/quote]En relisant les inquiétudes de certains quand au fait que la faille n’était pas corrigée, mais juste moins facile à exploiter, je me demandais si ça n’allait pas pousser du monde à faire plus sérieusement de l’ipv6.
A priori, si je me souviens bien, l’ipv6 a un systême de résolution complètement différent, non ?

#23

En lisant l’explication, je me disais qu’en enclenchant simultanément genre ( nb max de requètes acceptées -1 ) requètes longues sur le serveur, il y avait peut être moyen de prévoir un peu mieux le port de la (nb max de requètes acceptées) iême requète.

Il y a ça aussi:
bortzmeyer.org/faille-dns-em … ement.html

#24

Le test simple: [quote]roc@roc:~$ dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“89.3.163.99 is GOOD: 26 queries in 4.5 seconds from 26 ports with std dev 13625.33”[/quote]avant correctif, j’avais:[quote]roc@roc:~$ dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“89.3.163.99 is POOR: 26 queries in 4.5 seconds from 1 ports with std dev 0.00”[/quote] :wink:

#25

hello,

A priori même en ipv6 on aura besoin du protocole dns, sans faire donner de cour ipv6 permet d’adresser sur 128bits avec quelque amélioration de la stack ip.

C’est tout à fait ça, d’ou le patch qui alloue aléatoirement les ports source, les id’s’.

#26

Aïe aïe aïe! Ça se gâte! Dan Kaminsky ne comptait dévoiler les détails de la faille que début août à la conférence Black Hat pour laisser le temps aux ISP de patcher leurs serveurs mais un petit malin, expert en reverse engineering, semble avoir mis le doigt sur le mécanisme de la faille.

Ce qui fait dire à Dan Kaminsky: Patch. Today. Now!
doxpara.com/

Article:
theinquirer.net/feeds/rss/ge … re-details

#27

Je ne sais pas s’il a publié un proof of concept de son truc, mais à partir du moment où on publie quelques lignes de codes, on peut être sur qu’elles vont être reversées.
J’avais plutôt lu que le mec en question avait réussi à déduire certaines infos et avait trouvé la faille à son tour en cherchant un peu et en recoupant quelques infos.

#28

Bon, mon ISP (Belgacom) semble avoir patché mais son router/firewall déclenche une mise en garde avec le test du blog de Dan Kamniski.

Comme je suis prudent et que j’ai quand même un certain nombre d’utilisateurs derrière mon router, j’ai mis OpendDNS comme serveur DNS. Je viens de le tester et lui semble parfaitement OK.

opendns.com/

A première vue, la résolution est aussi rapide qu’avant. C’est quoi encore la commande qui fait un timing de la résolution?

Edit: J’ai trouvé. L’option -v de la commande host donne le timing de la résolution.

#29

quote=“ripat”
Comme je suis prudent et que j’ai quand même un certain nombre d’utilisateurs derrière mon router, j’ai mis OpendDNS comme serveur DNS. Je viens de le tester et lui semble parfaitement OK.

opendns.com/
(…)[/quote] Voilà. C’est ça… :mrgreen:
Comme tu es prudent, tu préfères donc prendre tes infos de DNS auprés d’un prestataire privé qui pourrait, mettons, faire payer la retransmission des noms de domaines (ou accélèrer certains domaines et pas d’autres) et ne retransmettre correctement que ceux qui ont payé, ou bien rediriger ou il veulent n’importe quelle URL.
Tu préfères donc utiliser ce service privé plutôt que le service public dns à cause d’une faille bientot obsolète pour cause d’ipv6, et qui n’a toujours pas d’exploit dix ans aprés sa découverte…

Bon. :smt005

Pour info, j’ai réalisé que le “cache poisoning” ne pouvait intervenir que si le serveur acceptait des données entrantes. Si vous avez des dns non récursifs ou au pire secondaires uniquement pour des domaines logés en primaire uniquement sur des serveurs non récursifs (= le cas répandu des serveurs de zone intranet qui ne chargent rien venant de l’exterieur), ils ne sont pas susceptible d’être attaqués. Pas la peine de toucher à vos vieux 386 servant de dns d’entreprise sous bo (dommage pour ceux qui l’ont déjà fait :laughing: ).

#30

[quote]Comme tu es prudent, tu préfères donc prendre tes infos de DNS auprés d’un prestataire privé qui pourrait, mettons, faire payer la retransmission des noms de domaines (ou accélèrer certains domaines et pas d’autres) et ne retransmettre correctement que ceux qui ont payé, ou bien rediriger ou il veulent n’importe quelle URL.
Tu préfères donc utiliser ce service privé plutôt que le service public dns à cause d’une faille bientot obsolète pour cause d’ipv6, et qui n’a toujours pas d’exploit dix ans aprés sa découverte…

Bon. :smt005 [/quote]
Parce que tu penses qu’on peux faire plus confiance au service public en ce moment…? :mrgreen:

#31

[quote=“tntprog”]quoteTu préfères donc utiliser ce service privé plutôt que le service public (…)
Bon. :smt005 [/quote]Parce que tu penses qu’on peux faire plus confiance au service public en ce moment…? :mrgreen:[/quote]Bah y a pas encore le service minimum dns garanti ?
Mais que fait Sarkocescu ?

#32

[quote=“mattotop”]Comme tu es prudent, tu préfères donc prendre tes infos de DNS auprés d’un prestataire privé qui pourrait, mettons, faire payer la retransmission des noms de domaines (ou accélèrer certains domaines et pas d’autres) et ne retransmettre correctement que ceux qui ont payé, ou bien rediriger ou il veulent n’importe quelle URL.
Tu préfères donc utiliser ce service privé plutôt que le service public dns à cause d’une faille bientot obsolète pour cause d’ipv6, et qui n’a toujours pas d’exploit dix ans aprés sa découverte…[/quote]

Je pensais être le seul à voir les méchants partout mais apparemment on est déjà deux…

Quant au caractère public et désintéressé de mon ISP, j’ai des doutes.

#33

des news toutes fraiche sur zataz concernant la faille

zataz.com/news/17479/DNS-Cac … ploit.html

[quote]Si la faille a été “rustinée”, elle est très loin d’être corrigée. La société Zynamics a diffusé lundi, par erreur, le concept de cette faille via un reverse engineering, une étude de la dite faille par un certain Halvar Flake, qui n’est rien d’autre que le patron de cette PME, Thomas Dullien [lire].

Bilan, les experts s’inquiètent à savoir si des pirates vont maintenant exploiter ces données. L’ingénieur en informatique qui avait découvert cette faille, Dan Kaminsky, de chez IOActive, doit démontrer et expliquer cette faille le 6 août prochain, lors du Black Hat de Las Vegas. [/quote]

#34

Donc pour mon tout nouveau cache DNS ça pose problème c’est ça ?
'fin il est à jour et ne reçoit de requête qu’en loop.

#35

Et bien ça y est. Un exploit est publié et déjà intégré dans la suite Metasploit bien connue des sysadmin et… script kiddies.
blogs.zdnet.com/security/?p=1545

Si vous utilisez le DNS de votre FAI, testez sa résistance au bug. Il est temps.

#36

Pour ceux qui comme moi ont des serveurs sarge, j’ai fait un backport fonctionnel de bind9 etch patché.

deb boisson.homeip.net/debian sarge divers

dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“81.57.102.55 is GOOD: 32 queries in 545.4 seconds from 27 ports with std dev 18883.63”
:slightly_smiling:

Matt, tu sais que c’est le serveur de potato qui tournait :slightly_smiling:

#37

quote="ripat"
Quant au caractère public et désintéressé de mon ISP, j’ai des doutes.[/quote]Lui, non, mais son dns qui respecte la rfc, si. :wink:

#38

Bon. Ceci étant, il y a du nouveau, l’exploit vient de sortir:
caughq.org/exploits/CAU-EX-2008-0002.txt

#39

[quote=“mattotop”]quote="ripat"
Quant au caractère public et désintéressé de mon ISP, j’ai des doutes.[/quote]Lui, non, mais son dns qui respecte la rfc, si. :wink:[/quote]Je viens de penser: rien n’empêche de s’installer un dns cache patché, et de ne déclarer aucun dns autres que les root-servers. Ca m’étonnerais qu’eux ne soient pas surprotègés contre les attaques.

#40

C’est ce que je fais pour le DNS du lycée où je travaille.