Sécurité : Découverte d'une faille de sécurité critique dans OpenSSL de Debian
Posté par Amaury (). Modéré le 15 mai 2008.
En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l'ont été à partir d'un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé.
Cette vulnérabilité touche Debian ainsi que toutes les distributions utilisant des paquets Debian (Ubuntu, Xandros...).
Pour prendre un exemple parlant, imaginez Securor, un fabricant de serrures qui seraient utilisées un peu partout sur la planète. Au bout de deux ans, alors que des millions de personnes ont installé des serrures pour protéger leur maison, on se rend compte qu'en fait il n'existe que 3 modèles uniques de clefs, les autres ne sont que des copies d'un des 3 modèles d'origine. Si bien qu'un voleur peut très facilement concevoir un trousseau contenant les 3 modèles de clefs, en ayant la certitude que toute serrure rencontrée pourra être ouverte avec l'une de ces clefs...
Concrètement, si vous utilisez une Debian, ou dérivée, vos VPN peuvent être cassés (adieu confidentialité des échanges), des faux certificats peuvent être signés (adieu confiance en votre système de PKI), votre serveur SSH ne filtre plus grand monde (adieu système sécurisé)...
Que faire ?
- Mettre à jour votre distribution Debian pour installer les nouveaux paquet.
- Vérifier sur tous vos systèmes qu'une clef faible n'est pas présente. Pour cela, un outil est disponible : dowkd.pl
Si une clef faible est présente, il sera nécessaire de la générer à nouveau, avec tous les impacts que cela peut avoir (fichiers authorized_keys & know_hosts obsolètes...). Même problème pour les certificats : j'espère que personne n'a mis en place de PKI sous Debian depuis 2006, il va falloir regénérer les certificats...
- lire le wiki Debian http://wiki.debian.org/SSLkeys qui vous guidera pas à pas en fonction des logiciels installés sur votre machine.
NdM : lire également les articles sur Planet Debian-Fr.
![[en]](../images/en.png)
Le Debian Security Advisory (781 hits)-
Dowkd.pl - A télécharger absolument en cas de doutes ! (1762 hits)
-
Metasploit a généré les clefs faibles (690 hits)
![[fr]](../images/fr.png)
Journal Linuxfr déja paru à ce sujet (840 hits)-
Wiki Debian :à lire si vous ne savez pas quoi faire (817 hits)
-
... (226 hits)
> Lire la dépêche (329 commentaires, moyenne: 2,2).
Vous avez demandé le commentaire #931479.
Run by 
Cette page a été générée par Templeet en 0.0484s (dont 0.0048 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Discussion avec upstream sur la suppression des lignes incriminées
Globalement, je suis plutôt d'accord avec ceux qui trouvent que le DD doit discuter avec upstream avant de faire une modification qui peut être très sensible... et c'est ce qu'il a fait !
http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
Le message a été posté sur openssl-dev, et contient à la fin, après avoir exposé ses découvertes avec Valgrind et les deux lignes incriminées (l'emphase est de moi) :
What I currently see as best option is to actually comment out
those 2 lines of code. But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy. But on the other hand, I'm not even
sure how much entropy some unitialised data has.
What do you people think about removing those 2 lines of code?
Donc, contrairement à ce que je peux entendre un peu partout, le développeur savait qu'il y avait un impact sur l'entropie du générateur. Mais bon, je vous laisse parcourir le fil de discussion, il n'y a eu que trois réponses qui sont également en faveur de la suppression (mise en commentaire ou compilation conditionnelle) des deux lignes.
[^]Re: Discussion avec upstream sur la suppression des lignes incriminées
Heu oui, mais sauf que :
1- Comme l'indique Ben Laurie, cette liste est de fait surtout utilisée par les développeurs d'applications basées sur openssl, et pas vraiment par les gens qui développent openssl. Ce qui change la façon d'interpréter les mails qui y sont soumis (cf. ci-dessous).
2- Kurt commence son email par "When debbuging applications that make use of openssl using valgrind [...]", et les devs ont clairement pensé qu'il voulait simplement une astuce / un hack lui permettant débugguer/valgrind localement une application utilisant openssl (cf. la réponse du dev openssl : "If it helps with debugging, I'm in favor of removing them."). L'intention de Kurt (patcher un openssl utilisée en prod, et distribué massivement cette version) n'était absolument pas discernable.
3- Son email à la forme d'une simple question, et n'envoie pas son code sous forme de patch proposé pour intégration dans openssl. S'il avait envoyé un patch pour intégration upstream, les développeurs l'aurait lu attentivement et refusé (comme ils l'ont fait à chaque fois qu'un patch pour "corriger MD_Update pour valgrind" leur est présenté, ce qui était déjà arrivé avant le mail de Kurt, y compris dans le bugtracker d'openssl, et ce dernier aurait du googler), ce qui lui aurait permis de comprendre que c'est une mauvaise idée.
4- Il ne s'est pas présenté comme "mainteneur du paquet Debian", et il a encore moins annoncé son intention de balancer cette modif pour tout les utilisateurs d'openssl chez Debian et Ubuntu (on en revient au point 2).
Bref, "remonter ses modifications upstream", c'est ouvrir une entrée dans le bugtracker et y attacher sa modification sous forme de patch, et annoncer son statut et son intention de distribuer le patch.
[^]Re: Discussion avec upstream sur la suppression des lignes incriminées
1- Comme l'indique Ben Laurie, cette liste est de fait surtout utilisée par les développeurs d'applications basées sur openssl, et pas vraiment par les gens qui développent openssl. Ce qui change la façon d'interpréter les mails qui y sont soumis (cf. ci-dessous).
Sauf que c'est faux.
1°) le site d'openssl indique que openssl-dev est pour la librairie et pas les applis
2°) la majorité des messages concernent des messages propre à la librairie.
Ah ben oui c'est dur de vérifier les sources, faut savoir lire une mailing list
3°) ben laurie indique comme mailing list openssl-team. Petit hic, cette mailing list n'est pas indiqué sur le site. Et un google me sors que 63 réponse, face à plus de 12000 pour openssl-dev.
4°) Ben laurie invoque l'excuse qu'il avait pas vu ce qu'avait dit le dvp parce qu'il "n'a pas suffisament de bande passante". Sauf qu'il y a des interfaces web pour effectuer des recherches directement. interface web qui sont moins lourde que son blog. Pourtant il arrive a recharger son blog et à répondre dessus.
L'intention de Kurt (patcher un openssl utilisée en prod, et distribué massivement cette version) n'était absolument pas discernable.
Il était question de debugger openssl, et d'aider au debug des AUTRES applications (cf un mail ou quelqu'un indique le nombre d'erreur qu'il a en utilisant openssl vanilla (et a cause de lui) pour debugger une autre appli. (ca reste bien un probleme propre à openssl, vu que les erreurs sont provoqué par lui).
Quand tu debug une application, tu vas pas t'amuser a prendre la version de debug de libc6...
Sur les autres points je suis d'accord.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Discussion avec upstream sur la suppression des lignes incriminées
> le site d'openssl indique que openssl-dev est pour la librairie et pas les applis
Oui, je l'avais indiqué dans un post précédent mais j'aurais du le rappeller dans celui-ci aussi. Cest aussi ce qui est écrit dans le README des sources de la lib :
« If you would like to submit a patch, send it to openssl-dev@openssl.org with the string "[PATCH]" in the subject. Please be sure to include a textual explanation of what your patch does. »
La remarque de Damien Miller semble la plus pertinente : selon lui, la meilleur façon de s'adresse à upstream en étant lu (et qu'upstream sache qu'on s'adresse à lui, pas qu'on cherche du support end-user), ça reste le patch (diff -u) dans le bugtracker. Ce qui, dans le cas présent, aurait peut-être même permis au développeur Debian d'y trouver la précédente discussion sur le sujet.