Le weblog entièrement nu

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 (il y avait une explication sur le blog de Steinar Gunderson, mais elle ne semble plus être disponible). 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é.