Gestion des DNS : une faille sans précédent ?

[shwing]

News de ce matin:

FR:
http://www.clubic.com/actualite-150722- ... xtor=EPR-3
US:
http://www.kb.cert.org/vuls/id/800113


J'imagine qu'ipcop ne doit pas trop être vulnérable, car le service DNS est visible que sur la patte verte (bleu aussi ?) et qu'il faut attendre un correctif. Juste ?

A+



[doublon créé --> http://forums.ixus.fr/viewtopic.php?t=40969 ]

[Stirner]

Salut,

De ce que j'en ai compris un correctif doit voir le jour rapidement. Naturellement pas moyen de connaitre la nature exacte de la faille. On devrait en savoir plus le 7/08 prochain.

@+

PS: le lien pour tester votre dns :http://doxpara.com/ aimablement fournis par Dan Kaminski

[Gesp]

On sait ce qui peut se passer (introduire des données erronées dans le cache d'un serveur dns en répondant avant que la réponse véritable ne parvienne au serveur). C'est certainement pas super facile.
La requête à répondre comporte un identifiant sur 16 bits, donc il y a normalement toute une plage de numéros à tester avant de trouver l'Id qui va fonctionner.
Le normalement est parce que certains systèmes n'utilisent pas toute la plage des 16 bits, donc ils sont plus vulnérables si l'attaquant connait le système auquel il s'attaque.

Il faut que la réponse acceptable de l'attaquant arrive avant la réponse véritable donc la plage de temps est réduite à 10/100 millisecondes dans la pluspart des cas, même s'il est aussi possible de gagner un peu de temps en attaquant la machine qui doit fournir la réponse pour qu'elle réponde plus lentement.

Pour le détail de comment faire l'attaque, cela me concerne peu, à part pour tester si la correction est effective.

L'auteur de dnsmasq n'a pas été prévenu avant la révélation du pb, donc il s'est mis au boulot dès que le problème a été rendu publique.
Il a travaillé hiers pour intégrer le même genre de correction que dans bind (effectuer les requêtes dans une plage de ports au lieu de garder toujours #53).
Cette solution est actuellement en cours de tests.
J'ai compilé mais pas encore testé.

Au niveau d'IPCop, le premier problème est que les serveurs dns récursifs ne soient pas vulnérables et on n'y peut rien du tout, sinon de toute façon les réponses que fournira dnsmasq seront de toute façon vulnérables. C'est le problème des FAI.
Le second problème est que dnsmasq continue de fonctionner avec les serveurs patchés, ce qui devrait normalement être le cas sans modifications.

Le troisième est de voir si dnsmasq peut être succeptible d'être attaqué de la même manière qu'un serveur dns. Probablement oui, c'est pour cela qu'au lieu de poser la question sur le port 53 au serveur supérieur configuré, dnsmasq utilisera aussi dans le futur une plage de port de manière à ce que la combinaison numéro de port/ ID de requête soit plus difficile à trouver que le seul ID dans le temps limité entre l'envoi de la requête et la réponse du serveur DNS.

[Stirner]

Précision par nature de la faille j'entendais les détails techniques. Détails qui resteront confidentiels afin de laisser le temps aux divers acteur (fabriquant, éditeurs, admin) de corriger le problème. Mais c'est une super nouvelle, on a enfin une excuse :

" Mais non chérie c'est pas moi qui suis allez sur youporn, tu sais il y'a une nouvelle faille internet qui te redirige vers n'importe quel site..."

[tomtom]

Selon plusieurs sources sures, la black hat va être passionnante cette année

Bien que partisan du full disclosure, pour cette fois je pense que ce n'est pas une mauvaise chose.

Les faiblesses du protocole DNS et ses implémentations, on les connait depuis des années (voir attaque des anniversaires, faiblesse de l'aléa utilisé pour les ID, utilisation du port source fixe pour les requetes DNS).
Mais le méthode d'exploitation découverte justifie le fait de supprimer ces faiblesses pour diminuer grandement l'impact des attaques.

Si je puis me permettre, patchez !


t.