Il y a déjà eu plusieurs billets publiés ici et là au sujet du récent problème de sécurité portant sur OpenSSL sous Debian, mais certains (notamment que j'ai lus sur Planet Libre) contiennent des infos erronées qui donnent une illusion de sécurité. Donc, je me permets un résumé/rectificatif. Attention, c'est important, et il ne suffit pas de mettre à jour les distributions pour se retrouver en sécurité.
Le cœur du problème : pour des raisons tout-à-fait légitimes, et suite à une mauvaise communication avec les auteurs amont d'OpenSSL, les versions d'OpenSSL distribuées par Debian (et toutes ses dérivées : Ubuntu, Mepis, Linspire, Knoppix, etc.) utilisaient un générateur de nombres pseudo-aléatoires (pseudo-random number generator, que l'usage abrège en PRNG, et qu'un abus de langage abrège encore plus en RNG) absolument pas aléatoire, du genre de celui-ci en à peine mieux. On peut chercher des responsables pour les mener au bûcher, on peut essayer de faire en sorte que ça ne se reproduise pas, ou on peut essayer de corriger les effets néfastes. La première option ne m'intéresse pas, la deuxième a déjà été traitée par des gens bien (Linux Weekly News par exemple), je me concentrerai aujourd'hui sur la troisième.
Je ne vais pas vous faire un cours de sécurité informatique, mais une grande partie de cette sécurité repose sur de la cryptographie. Or, la cryptographie repose souvent sur des secrets, que le méchant adversaire pirate terroriste ne doit pas pouvoir deviner. En général, ces secrets sont générés aléatoirement. Par un RNG. Donc quand le RNG renvoie des résultats prévisibles, ça casse pas mal de choses.
Concrètement, le RNG d'OpenSSL était utilisé par un certain nombre d'applications. Je ne vous parlerai ici que des deux trucs les plus courants, je vous laisse lire le reste sur le wiki de Debian.
Premièrement, la génération de clefs. Toutes les clefs SSH et SSL
générées sur un système Debian ou apparenté au cours des deux
dernières années sont à jeter. Parce que le RNG étant ce qu'il est,
ces clefs sont en nombre très réduit, et qu'il est très facile de les
générer toutes, y compris les clefs secrètes. La liste de ces clefs
faibles est déjà plus ou moins connue, et les paquets OpenSSH de
Debian et Ubuntu l'intègrent déjà sous forme de liste noire pour
refuser les accès. Et il existe un script qui permet de vérifier si
une clef fait partie de cette liste, le fameux dowkd.pl.
Deuxièmement, l'utilisation de l'authentification par clef pour SSH. Les clefs de type DSA (ou DSS, c'est vaguement synonyme) sont souvent utilisées pour établir des connexions SSH sans mot de passe. Manque de bol, l'utilisation du protocole DSA a intrinsèquement besoin d'un bon RNG pour protéger la clef secrète (cf. l'explication mathématique). Je répète : quelle que soit la clef DSA, même vraiment aléatoire, quelle que soit sa date de création, elle n'est protégée dans une transaction que par un nombre aléatoire. Le simple fait de s'en servir sur une machine où le RNG est faible rend trivial l'accès à la clef secrète, autant pour l'autre bout de la connexion que pour n'importe qui sur le chemin. Donc toutes les clefs DSA sont à considérer comme compromises dès le moment où elles ont été utilisées sur une machine affectée par le bug. Malheureusement, il n'est pas possible d'établir une liste de ces clefs.
Voilà pour les effets. C'est assez dévastateur, il convient donc de prendre les mesures appropriées.
Pour les sites HTTPS : les vieilles clefs RSA (plus de deux ans) ne sont pas affectées. Les clefs RSA plus récentes doivent être remplacées, de même que toutes les clefs DSA. Pour vérifier votre site, cherchez l'algorithme de signature des certificats dans les « détails du certificat » (que votre navigateur doit vous afficher sur demande).
Pour les clefs SSH : pareil, les vieilles clefs RSA ne sont pas
affectées (mais je vous encourage quand même à les remplacer, ne
serait-ce que pour faire du ménage). Les clefs RSA plus récentes
doivent être remplacées, de même que toutes les clefs DSA.
Pour vérifier le type de votre clef, regardez la partie publique (le
fichier blabla.pub). S'il commence par ssh-dss ou ssh-dsa,
poubelle. Il est recommandé de créer les nouvelles clefs au format
RSA. Ça s'applique autant aux clefs des clients qu'à celles du
serveur (celles de /etc/ssh/ssh_host_*). Bien entendu, il ne suffit
pas de générer des nouvelles clefs, il faut aussi bloquer les
anciennes : c'est une excellente occasion pour faire le tour de tous
les fichiers authorized_keys et y faire du ménage. Le plus simple
est d'y virer toutes les lignes qui commencent par ssh-dss ou
ssh-dsa, voire carrément toutes les lignes tout court, et d'utiliser
ssh-copy-id pour remettre la bonne clef publique (la nouvelle, en
RSA) dedans.
Note : étant donné la proportion potentiellement énorme de clefs
compromises parmi les clefs DSA même « fortes », plusieurs
organisations ont choisi de refuser pour l'instant toutes les clefs
DSA. En particulier les machines *.debian.org, notamment Alioth,
mais aussi d'autres instances de GForge.
Je me permets de me répéter : beaucoup de clefs DSA, même si elles ne
sont pas dans la liste noire, sont compromises, quoi qu'en disent
dowkd.pl et ssh-vulnkey et consorts. Il suffit qu'elles aient
été, à un moment donné, utilisées sur une machine Debian ou assimilé
(et ça fait du monde). Il est donc vital de désactiver ces clefs.
Le plus direct est de régénérer une clef RSA (pour ne pas risquer
qu'elle soit compromise par la suite), après avoir mis à jour vos
systèmes bien entendu, et de faire un grand ménage de printemps dans
les authorized_keys.
Attention, je n'ai ici parlé que de SSH et HTTPS, mais ça a un impact sur beaucoup d'autres services, dès qu'ils utilisent SSL d'une manière ou une autre. GnuPG n'est pas affecté, mais les serveurs POPS, IMAPS, les VPN etc. sont à vérifier aussi. Le wiki Debian contient des instructions détaillées.
Voilà. Il n'y a pas lieu de paniquer, mais il faut quand même se bouger pour rétablir une situation normale, et ne pas garder une illusion de sécurité.
