La vulnérabilité OpenSSH / SSL affecte aussi les systèmes non-Debian
Par hm le vendredi, mai 16 2008, 19:01 - Informatique - Lien permanent
Le bug du générateur aléatoire déterministe des Debian depuis 2006 fait grand-bruit actuellement dans la petite communauté du libre. On râle, on peste, mais pire : on ne voit certainement que la moitié de l'iceberg. Cette faille est probablement une des plus importantes de ces dernières années.
Je ne détaille pas la faille de sécurité en elle-même, d'autres que moi l'ont déjà fait de façon extrêmement claire (merci yoyo pour le lien). Non, ce qui m'interpelle davantage, c'est que cette faille va affecter tous les systèmes. Administrateurs de Gentoo, RedHat, Suze ou même *BSD, tout le monde est déjà touché par cet énorme trou de sécurité.
C'est un de mes collègues, enseignant et chercheur dans le domaine de la sécurité de l'information [1], qui m'a fait prendre conscience des conséquences que peut avoir ce "bug" pour l'ensemble de la communauté. Projetons-nous dans 4 mois, après que l'effervescence dûe à ce "petit pépin" soit retombée : les Debian du monde entier sont patchées, et il ne reste guère que quelques inconscients pour se faire hacker leurs machines. Bref, le train-train quotidien. C'est la rentrée universitaire, et j'ouvre par wagons entiers des comptes pour les nouveaux étudiants : parmi ces derniers, quelques-un, plus "bricoleurs" que les autres, ont déjà un portable sous Linux. Ce portable tourne maintenant sous Fedora, et le premier travail de cet étudiant sera bien entendu de déposer sa clef publique sur les serveurs auxquels il a accès, afin de s'éviter la corvée des mots de passe. Or il se trouve que sa paire de clefs SSH a été générée 2 mois avant la publication du DSA 1571-1, alors que son portable tournait sur... une Ubuntu ! Bien sûr, il a ré-installé depuis son PC avec une distrib non affectée par le bug : Fedora, Gentoo, BSD, peu importe au fond, car il a utilise toujours des clefs générée avec un moteur buggé, et qui font donc partie des paires de clefs "disponibles au catalogue" pour un hacker. Et mon système, qui n'a jamais été affecté par ce bug, se trouve en danger malgré tout, car sa clef, toute compromise qu'elle soit, n'en est pas moins valide : tout serveur OpenSSH va l'accepter sans broncher !
Alors quelle solution ? Déjà, probablement, mettre en place, comme l'a fait Debian, un package conjoint à openssh, contenant une blacklist permettant au moins d'interdire l'accès aux clefs incriminées.
D'ici là, un conseil : faites tourner chaque nuit dowkd.pl en mode "user" afin de contrôler les clefs installées sur vos systèmes...
Mise à jour (19:20) : le problème a été signalé sur le bugzilla de Gentoo, et un patch proposé, on n'attend plus que l'accord des responsables sécurité pour inclure le patch. Souhaitons qu'il ne tarde pas trop.
Notes
[1] merci Carlos !
Commentaires
Hello Anigel,
Il aura fallu un méchant bug pour te secouer les puces et te faire poster (enfin) un nouvel article ! :p
Ce dernier est intéressant mais il lui manque une partie utilisateur ! En gros il est question du "dowkd.pl", d'un blacklistage des clés incriminés etc. enfin de tout ce qui est important <u>d'un point de vue administrateur</u>.
Mais quid des utilisateurs ??? Le pauvre étudiant qui va arriver avec sa clé "trouée" et se la verra refuser ... Comment pourra-t-il, à moindre frais (ie sans y passer 2 jours) renouveler ses clés, les "redistribuer" à ses contacts et les prendre en compte dans son système (à la place des anciennes et sans tout réinstaller).
L'utilisation d'un site de gestion de clé publique est-elle un gain de temps dans ce cas ? Est-ce l'occasion pour y passer ? Et d'une manière générale, quel est ton avis sur ce système de partage "public" de clés publiques ?
Enjoy !
Le retour du beau temps, l'appel de la nature, la flemme aussi... Tout ça ;-).
> Ce dernier est intéressant mais il lui manque une partie utilisateur ! En gros il est question du "dowkd.pl", d'un blacklistage des clés incriminés etc. enfin de tout ce qui est important <u>d'un point de vue administrateur</u>.
Merci pour le compliment, mais tu restera quand même sur ta faim xD : cette faille est clairement un problème d'administrateur. Elle requiert de disposer des droits de root sur son système pour la corriger, et côté usager il n'y a pas grand-chose à faire si ce n'est re-générer une nouvelle paire de clefs. Et partant du principe qu'un usager qui se sert de cette fonctionnalité saura le (re)faire, je n'ai pas détaillé. Les tutos ne manquent d'ailleurs pas sur le net ;).
> Mais quid des utilisateurs ??? Le pauvre étudiant qui va arriver avec sa clé "trouée" et se la verra refuser ... Comment pourra-t-il, à moindre frais (ie sans y passer 2 jours) renouveler ses clés, les "redistribuer" à ses contacts et les prendre en compte dans son système (à la place des anciennes et sans tout réinstaller).
Une clef DSA n'est pas une clef PGP, il ne s'agit pas là de signer des mails, mais bien de l'accès à des serveurs. Autrement dit : rien à voir avec les serveurs de clefs publiques dédiés aux architectures de mail sécurisé : PGP n'est d'ailleurs absolument pas en cause sur ce sujet. Et pour ce pauvre étudiant je ne m'inquiète pas trop : lorsque le papier vient à manquer dans l'imprimante, il n'écoute que son courage et vient me voir afin de tenter de trouver une solution à la "panne", alors dans le cas d'une clef... Je suppose qu'il trouvera aussi le chemin xD !
> L'utilisation d'un site de gestion de clé publique est-elle un gain de temps dans ce cas ? Est-ce l'occasion pour y passer ? Et d'une manière générale, quel est ton avis sur ce système de partage "public" de clés publiques ?
Comme je le disais : ce n'est pas le sujet. Et si ça l'était, je n'aurais pas écrit ce billet : je connais trop mal ces systèmes pour discourir dessus ;).
Très jolie utilisation de <DATA> dans le script Perl. On dirait du Locomotive BASIC.