Dernière update, promis (24/07/2008 - 18:21) : ma théorie personnelle sur le tout dernier pas de l'attaque, la corruption du cache, et qui s'avère être la bonne.

Nouvelle update (10/07/2008 - 08:32) : Thomas Ptacek et Dino Dai Zovi publient chacun un nouveau billet suite aux informations que Dan Kaminsky leur a communiquées. Si je ne connais pas Ptacek, j'ai eu l'occasion de discuter un peu avec Dino, et je dois avouer que s'il nous dit que c'est sérieux, je lui fait confiance. Donc c'est sérieux. Et il faut patcher, mais ça, vous le saviez déjà, puisque comme je le disais en fin de billet, ce n'est pas quand les choses deviennent graves qu'il faut agir :)

Je ne sombre pas non plus dans l'alarmisme. Vous trouverez dans les avis les mises à jour nécessaires, qui portent pour l'essentiel sur la randomisation du port source des transactions émises par le resolver. Vous pouvez aller jeter un coup d'œil chez Bruno pour un executive summary.

Côté exploitation, comme je l'écrivais plus tôt en commentaire, je reste sur mon scénario. La grosse faille réside dans la possibilité de brute-forcer l'ID de transaction, probablement en exploitant cette histoire requêtes multiples. Le port source fixe vous évite quant à lui d'avoir à deviner aussi ce paramètre, ce qui compliquerait pas mal les choses. Je pense qu'il s'agit donc d'émettre des requêtes à destination d'un domaine arbitraire contrôlé pour récupérer de quoi modéliser le générateur d'ID. Ensuite, vous passez au spoof proprement dit en passant sur des requêtes à destination d'un vrai domaine, en renvoyant les réponses adhoc, en masse probablement. Si une passe, vous avez pollué le cache. Bingo. Classique dira-t-on, mais l'avancement doit résider dans des chances de réussites très fortes.

Et non, ça ne change pas mon avis quant aux articles cités précédemment...

Vala pour ce matin ;)


Parce que bon, soyons bons joueurs, ce n'est pas parce que c'est Dan Kaminsky, le grand et vénéré Deputy Dan, qui a levé le lièvre qu'il faut douter du truc. On pourra certes se permettre de douter de l'impact annoncé, comme toujours, mais je pense qu'il y a effectivement quelque souci à se faire. Ma position est cependant plus proche de celle adoptée par Thomas Ptacek dans son dernier billet et qui diffère pas mal du buzzz naissant : pas grand chose de transcendant au niveau de la nouveauté technologique, mais un bon assemblage de vieux crus.

Le problème essentiel, c'est que pour le moment, on n'a aucune information technique sur cette faille. Juste des pistes de réflexion, et donc beaucoup de conjectures. Ce qu'on peut déduire des avis, c'est que nous avons trois problèmes principaux :

  • un manque d'entropie sur certaines implémentations dans la génération de l'identifiant de transaction codé sur 16 bits, ce qu'on savait déjà ;
  • un manque de randomisation dans la sélection du port source pour les requêtes DNS, mais connu encore une fois, et avec seulement 16 bits d'entropie[1] ;
  • une technique pour augmenter les probabilités de réussite de l'attaque, connue également.

Si des paris devaient être pris, je pencherais donc pour un savant mélange des trois. Une pincée de bruteforce de l'ID en aveugle, avec un soupçon de requêtes RR multiple, le tout enfourné sur un serveur dont le port source est fixe, ou facile à trouver. Ce dernier point est d'ailleurs manifestement un facteur clé. Lorsqu'on lit les advisories[2], il apparaît que la randomisation du port source soit un facteur d'atténuation important de cette faille. en ce qu'il évite de se taper 16 bits de plus...

Toujours est-il que pour le moment, l'auteur ne semble vouloir laisser filtrer aucun détail, pour sauver l'Internet de la catastrophe nous explique-t-il... Jusqu'à BlackHat, bien évidemment... Toujours est-il que si paris il y a, ils porteront plus sur le tee-shirt qu'il portera lors de son talk que sur le contenu réel de cette faille.

Voilà en tout cas matière à remettre au goût du jour quelques pratiques saines de configuration de serveurs DNS, comme la toute simple restriction des accès récursifs à ses serveurs, ou carrément la séparation des serveur faisant autorités de ceux offrant la récursivité. Et accessoirement remettre au goût du jour quelques règles de filtrage basiques contre le spoofing. Ou tout simplement suggérer une nouvelle que les faiblesses avérées doivent être corrigées sans attendre qu'elles se révèlent vraiment exploitables...

Et que les "Patch Tuesday"[3] deviennent de plus en plus drôles :)

Update (10/07/2008 - 07:13) : trouvé sur le blog de Stéphane Bortzmeyer, un script pour tester si votre serveur DNS favori utilise un port source fixe pour résoudre vos requêtes.

Update encore : un billet qui montre les stats de consultation leakées par l'outil proposé sur Doxpara.com :)

Update à nouveau : une spéculation intéressante, de la part de Halvar, qu'on dit très très proche de la réalité.


Et pendant que certains publient leurs outils pour attaquer les sessions SSH faibles, d'autres trouvent encore des format strings... Dans OpenSSH[4]...

Notes

[1] Comme OpenSSL en fait :)

[2] À condition qu'ils ne soient pas trop gentils, voire erronés...

[3] Celui de juillet en l'occurence.

[4] Version portable, en SSHv1 seulement, et manifestement pas exploitable...