[failles] Déni de sécurité

Nous venons d'avoir deux beaux exemples de ce que l'on pourrait appeler un "déni de sécurité" de la part d'un projet libre et d'un projet proprio, qui méritent bien que je passe 2 minutes à rédiger ce billet.

Premier cas : la faille dans le serveur DNS d'OpenBSD. Je n'ai pas eu le temps de lire le papier en entier, mais d'après ce que je comprends, l'algorithme (du moins son implémentation) générant les nombres aléatoires utilisés dans le champ Transaction ID est biaisé, ce qui permet, si l'on en croit l'auteur, de deviner le prochain ID avec une grande probabilité si on arrive à sniffer les 10 ou 15 précédents. D'où corruption de cache, toussa. Réactions des intéressés :

• FreeBSD : on patche
• NetBSD : on patche
• DragonFlyBSD : on patche
• MacOS X : on patchera bientôt
• OpenBSD : on s'en fout ("OpenBSD is completely uninterested in the problem", "the problem is completely irrelevant in the real world")

Deuxième cas : la publication de la version 8.1.2 d'Adobe Acrobat/Reader. Absolument aucun détail n'est donné dans le bulletin original. Dans le doute, que vont faire les admin ? Patienter en attendant d'être sûrs, afin ne pas perdre de temps à qualifier un produit qui ne le mérite peut-être pas. Bon d'accord, le bulletin indique : "the update includes several important security fixes, among them a few of critical severity that could be remotely exploitable". Ce qui me frappe le plus dans cette phrase, c'est le "a few". Oh, vous savez, il n'y pas tant de remote code executions que ça dans notre produit... On ne sent pas du tout qu'ils essaient de minimiser alors qu'ils ont une bombe entre les mains. D'ailleurs, ces failles sont déjà exploitées dans la nature. Trop tard.