Le 29 avril 2014, l'université Technion a
publié un communiqué
ridicule
prétendant que leurs chercheurs avaient trouvé un moyen de subvertir
les requêtes DNS. C'est apparemment sa reprise
par The
Hacker News le 5 mai qui a lancé le
« buzz ». Comme le communiqué du service marketing
de l'université, l'article de The Hacker News est fertile en
superlatifs et, à le lire, on se dit
qu'Heartbleed n'était que de la petite
bière. Sauf que tout est tellement gonflé qu'il est très difficile
d'apercevoir le vrai problème de sécurité derrière cette accumulation
de sensationnalisme.
Revenons aux choses sérieuses. Lorsqu'un client veut utiliser le
DNS pour résoudre un nom de
domaine en données (par exemple l'adresse
IP), il s'adresse à un résolveur
DNS. Les logiciels les plus courants pour cette fonction sont
BIND et Unbound. Le
résolveur n'a pas d'informations propres, il doit les obtenir auprès
des serveurs faisant autorité pour la zone
considérée. Par exemple, linuxfr.org a deux
serveurs faisant autorité :
% dig +short NS linuxfr.org
ns1.tuxfamily.net.
ns2.tuxfamily.net.
Lequel des deux sera interrogé par un résolveur dont le client veut
visiter ? Cela dépend d'un algorithme
suivi par le résolveur, qui prend en compte le
RTT des réponses lors des requêtes précédentes,
mais aussi une certaine dose de hasard, à la fois pour voir si les
temps de réponse ont changé, et aussi pour compliquer la tâche d'un
attaquant. En effet, lors de certaines attaques, notamment l'attaque
d'empoisonnement Kaminsky, l'attaquant a besoin de savoir quel
serveur faisant autorité sera utilisé. En tirant partiellement au
sort, on complique sa tâche.
Venons-en à l'attaque elle-même, documentée dans un
article à Usenix (et je ne sais pas pourquoi l'université de
Technion a choisi de buzzer maintenant, sur une
publication de l'année dernière). Son titre résume bien le peu d'étendue de
l'attaque : « Subverting BIND's SRTT Algorithm Derandomizing NS
Selection ». Les auteurs ont trouvé une méthode (astucieuse,
je ne dis pas le contraire) pour influencer l'algorithme par lequel un
résolveur BIND choisit le serveur d'une zone à
qui il va parler pour résoudre les noms dans cette zone. (Notez que ce
n'est donc pas une vulnérabilité DNS mais une - faible - vulnérabilité BIND.)
Lorsque cette attaque est en cours, l'attaquant peut donc forcer
l'usage d'un serveur faisant autorité, parmi tous ceux de la
zone. Cela diminue un tout petit peu le nombre de paramètres qu'un
attaquant qui tente un empoisonnement doit deviner. Pourquoi « un tout
petit peu » ? Parce qu'un attaquant doit deviner bien d'autres
paramètres ( pour les détails). Et
celui-ci, le serveur interrogé, est un des moins importants, la grande
majorité des zones (comme linuxfr.org cité plus
haut), n'ont que deux serveurs faisant autorité ! L'attaque, même
quand elle réussit complètement, ne fait donc gagner qu'un seul bit
d'entropie à l'attaquant... J'emprunte donc une conclusion à Dan
Kaminsky « While a neat trick, the recent DNS security
research by the Technion students is in no way a critical
vulnerability in BIND. »
Un résumé de l'attaque et de ses conséquences pour BIND avait été
fait par
l'ISC (et réitérée
après la nouvelle vague de buzz).
Par contre, la correction promise n'a pas encore été
apportée. Une bonne réfutation avait été écrite l'année dernière
par Tony
Finch (et la relance marketing de cette année n'en a pas tenu
compte.) Un des auteurs de l'article original a publiquement dénoncé le gonflage.
À noter que
DNSSEC résout complètement ce
problème : quel que soit le serveur interrogé, on peut vérifier la
validité des données.