Salut les moules,
 
à propos de la faille DNS des DSA http://www.debian.org/security/2008/dsa-1603 http://www.debian.org/security/2008/dsa-1604 et http://www.debian.org/security/2008/dsa-1605
 
dont on parle également ici:
 
http://lwn.net/Articles/289138/
 
 
Y a des trucs que je comprends pas bien.
De ce que je crois comprendre, ça n'affecte que les resolvers, donc potentiellement tous les clients et serveurs. La faille c'est que le port source est prédictible et qu'avec des ID DNS 16bits, c'est assez fastoche. Mais ce que je ne saisis pas bien:
1) Debian dit que pour corriger le problème il faut utiliser BIND9 et vérifier qu'on a pas une option à la con qui désactive la randomization de port. Pour le resolver de la libc, pour le moment il n'y aurait pas de solution.
2) sur une RHEL 4.5 avec un 2.6.9, quand je lance une rafale de 'dig', ça bind sur le même port. Si je lance une rafale 1s plus tard, ça rebind sur un autre même port (en incrémentant). La je vois le problème, mais comment diable ça se fait que deux programmes pas root se retrouve binder sur le même port ? J'ai stracé le truc, et ça bind sans préciser de port. OK c'est de l'UDP mais c'est pas très glop que 2 invocations successives se retrouve sur le même port. Ca peut mettre un sacré souk. Et pour cause. 'tain j'avais jamais réalisé que le noyau 'recyclé' à se point les sockets UDP.
3) par contre sur un noyau récent >= 2.6.24, quand je fais des rafale de bind, et bien ça utilise des ports bien aléatoires pour chaque invocation. Donc c'est pas vulnérable.
4) donc on peut avoir une libc vulnérable, mais avec un noyau récent, on est protégé donc.
5) comment diable bind9 fait-il pour implémenter la randomization de port (RTFS je sais) ?

J'ai pas vérifié dans les sources mais lors du bind y a moyen de passer des options via les flags (notamment SO_REUSEADDR et SO_REUSEPORT) pour réutiliser des anciennes sockets dans un certains états.
1. Soit y a un comportement par défaut qui ne réutiliser pas les sockets lorsqu'on ne l'indique pas
2. Soit y a un flag permettant de dire explicitement que l'on ne désire pas réutiliser de socket => random
3. Peut on décider du port source ? Je me rappelle plus...

Sur la page de l'isc http://www.isc.org/index.pl?/sw/bi [...] e=9.3.2-P2
Dernier upcoming fix il en parle.

Merci pour le lien. J'avais jamais fait gaffe sur ces sockets UDP: je pensais pas que le noyau recylé immédiatement, j'aurais pensé qu'il observait un temps minimum. Mais là avec un vieux noyau, c'est systématique.

Oui mais attention: SO_REUSEADDR est "concue" pour des sockets connectées, surtout applicable pour pouvoir se bind() à nouveau à certaines adresses même s'il y a des états TIME-WAIT. Si on veut faire des requetes randoms, c'est stupide: si on met le flag, ca veut dire qu'on souhaite réutiliser la même socket, donc forcément la même adresse source.

SO_REUSEPORT n'a été créé (amha) que pour du multicast, qui permet à plusieurs process de partager un même port (c'est plutot nécessaire pour le multicast justement). L'utiliser pour autre chose, c'est s'exposer à de gros soucis (c'est pour ca que _tous_ les process souhaitant utiliser ce flag doivent le signaler, sinon le noyau refusera la création d'une deuxième socket avec la même adresse).

1. politique de recyclage interne du noyau sur les buffers. Si tu redemandes la même adresse dans un délai très court, fortes chances que le noyau te réutilise la même struct.
2. non, c'est hors du champ du programme. Le process ne controle rien sur l'utilisation des sockets après le close(). Si tu veux forcer, il faut recréer une socket en s'assurant que l'adresse (IP et/ou port) soit différente.
3. ca dépend du sens. Tu peux spécifier le source d'une réponse d'un serveur quand tu lies l'espace de nom voulu avec la socket, via un bind(). Mais c'est le noyau qui décide du source quand tu utilises une socket sans lier, car justement, tu n'associes pas d'espace de nom (c'est de là que vient le mot "bind" ), la socket est anonyme.

Edit: ah oui, je vois que c'est pas très clair: quand je parle d'adresse, c'est celle de la socket, donc pour inet, c'est IP+port.

Comme quoi la petite fonctionnalité de random de port sous linux, c'était pas mineur du tout.

notez que djbdns n'est pas vulnérable lui, justement parce qu'il randomise le port.

De même pour PowerDNS. D'ailleurs au boulot on a profité de cette histoire de faille pour totalement switcher de bind9 vers pdns sur nos serveurs de noms ; ça faisait un moment qu'il en était question pour des raisons techniques (en termes de performances) et certaines limitations de bind, la faille aura juste été l'évènement déclencheur "de trop".

Un mail interessant de Stéphane Bortzmeyer sur la liste dns-fr du CRU ajourd'hui :

 
Pas encore fini de lire le PDF mais ca a l'air de contenir pas mal d'infos techniques interessantes

Oui enfin la faille n'est pas propre à Bind, mais est due à la conception du protocole DNS si je ne m'abuse
Et elle est juste rendue plus difficilement exploitable par l'utilisation de ports sources aléatoires, et non pas corrigée

exactement
 
les patchs permettent juste que l'exploit ne soit pas facilement utilisable

Dites j'ai pas bien compris  la différence sur cette histoire avec un classique "man in the middle". Vous pourriez m'aiclairer sans être top technique ?

 
MITM tu te mets entre le serveur et la victime.
 
La tu envoies des requetes au serveur que tu sais qu'il va chercher à résoudre en demandant à un autre serveur, et tu en profites pour lui envoyer ta réponse à toi. Tu pollues sont cache de noms avec des données falsifiées.

Hum  donc si je reprends :
 
1) requête à un serveur A  qui ne l'a pas dans son cache
2) ce même serveur  demande à un serveur B supérieur/gérant la zone
3) tu te fais passer pour le serveur B  
 
Ok.  En cois le random de port va éviter le fait de se faire passer pour le serveur B ?

 
Parce que on ne sait pas sur quel port il faut répondre pour se faire passer pour B?
Parce qu'on ne peut pas prédire le transaction ID?

Si tu sais pas de quel port le serveur A envoit ses requêtes, c'est pas évident de lui envoyer ta reponse forgée.
Si c'est toujours le même, il suffit que le serveur A ait interrogé ton DNS pour savoir lequel c'est.

Ah oui effectivement j'y avais pas pensé    
 
merci

 
Faudra encore quelques années avant que tout le monde ait patché le résolveur de son routeur domestique
16 bits

 
Les opérateurs font ca à distance, ils ont des backdoors sur les routeurs qu'ils distribuent (si si).
 

 
Normalement, avec le port, ca devrait aider, mais non

J'ai decouvert ca (je vis au quebec) lorsque le fournisseur d'acces de mes proprios (qui touchent pas une bille sur l'info) a modifie des parametres de connection a distance... alors que j'avais change le mdp du routeur et que l'acces distant est interdit  
Imaginons que la backdoor se retrouve plus ou moins publique...  

 
Repris de l'excellant blog de Cédric Blancher ( http://sid.rstack.org/blog/index.p [...] la-baraque )
 
Comme quoi randomiser le port c'est bien mais c'est pas forcement le plus "utile"

Il parle même pas de SecureDNS

Les opérateurs ne bloquent pas le nombre de pc au niveau des modems chez vous ? Les utilisateurs ajoutent pas des routeurs pour partager après ?
En tout cas, ici (.be), c'est la norme.  
 
Mais ce que je comprends vraiment pas, c'est ou se situe la nouveauté dans cette "faille", et bruit que ça fait, alors que les dns fonctionnent comme ça depuis toujours ...  

 
Non
 

 
Ben c'est le problème des failles protocolaires justement. Si tu en avais conscience avant de la corruption possible de cache aveugle, il fallait le dire, tu avais droit à ton 1/4 d'heure de célébrité au black hat.

 
Justement, je vois pas ce qu'il y a de spécial. C'est un simple cache poisoning, c'est connu depuis les années 90.
Le paradoxe des anniv, le port source fixe et la longueur du tID sont un ensemble de facteurs aggravants, mais pas un exploit ou une faille en soi ...
Donc soit c'est beaucoup de bruit pour rien, soit, je raté le point et je compte sur vous

Le truc nouveau c'est qu'ils utilisent des sous-domaines pour empoisonner un élément du domaine donné : http://blog.invisibledenizen.org/2 [...] eaked.html
(les commentaires 3,4 et 5)

Chez moi ils fournissent carrement un modem-routeur avec4 ports, donc fait pour partager la connection sur un reseau domestique    
Mais ils ont quand meme une backdoor...

Bon, vu que ça parle DNS, et au vu des dernières failles de BIND, je me pose une question simple...

Qu'elles sont aujourd'hui les alternatives viables à BIND ?

Pour l'instant pas beaucoup de réponse (qui tienne la route), sauf peut-être un certain "Unbound" qui sort tout juste du papier cadeau (première release stable en mai dernier), ça a l'air sérieux, c'est open source, les objectifs sont fixés et c'est distribué sous licence BSD ()...

Certains ont déjà testé, j'aimerais avoir des retours, mais dur d'en trouver pour un produit si... récent...

http://www.unbound.net/

Pas de ML ou d'outils dédiés ou tu pourrais lire ces fameux retours ?

Y'a une ML, quasi vide pour l'instant les seuls retours concernent des bug
 
(Sinon, pour un peu mieux comprendre le problème de "LA" faille DNS > http://www.milw0rm.com/exploits/6130 )

Enfin, d'apres la ML il ressort un truc intéressant:
Le labo qui développe Unbound développe aussi NSD, les 2 solutions sont développées en parallèle chacune ayant un but bien définis (NSD > autorités ; unbound > cache haute performance).

Donc ma question s'applique aussi pour NSD

Comment je peux tester si mon FAI a patche?
Quelqu'un a un petit script pour tester un serveur DNS donne?

djbdns et powerdns ressortent assez souvent dans les discussions sur les alternatives à Bind
 
Et encore une fois ce n'est pas une faille de bind mais du protocole DNS  
 

http://www.bortzmeyer.org/files/noclicky-1.00.pl

Vous avez un serveur DNS public (patche) a me recommander?

Y'a des failles relatives uniquement à BIND hein, et c'est pas nouveau  

 
OpenDNS ont patché il me semble

tiens dnsmasq n'a pas l'air vulnérable

Pasque c'est encore le plus utilisé, c'est tout
 
C'est comme Windows