# Packahe OpenSSL Debian vulnérable **URL:** \ **Category:** Pause Café\ **Created:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764 "2016-02-20T17:35:07Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Platinium](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/9f8e36/32.png) [@Platinium](https://www.debian-fr.org/u/Platinium)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/1 "2016-02-20T17:35:07Z")
Salut à tous, je ne sais pas ceux qui ont suivi l’affaire mais suite à une vulnérabilité dans le package Debian de OpenSSL, une nouvelle version a été publiée. [secunia.com/advisories/30220/](http://secunia.com/advisories/30220/) [linuxsecurity.com/content/view/136865/](http://www.linuxsecurity.com/content/view/136865/) Ce qui m’étonne dans cette histoire, c’est que seul la distrib Debian est affectée par cette faille. Je ne savais pas que les binaires eux-mêmes étaient customisés dans les pakages Debian. Je pensais que c’était uniquement les fichiers de conf et les hiérarchie des fichiers qui était touchée… ---
**Author:** ![dimm](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/e9bcb4/32.png) [@dimm](https://www.debian-fr.org/u/dimm)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/2 "2016-02-20T17:35:07Z")
J’ai suivi l’affaire 😉 : [http://forum.debian-fr.org/viewtopic.php?f=1&t=14173](http://forum.debian-fr.org/viewtopic.php?f=1&t=14173) ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/3 "2016-02-20T17:35:07Z")
Une fois de plus: ce n’est pas une question concernant la programmation, il me semble, non ? Sinon, ce ne sont pas les binaires qui sont patchés, mais les sources. C’est un détail. Quoi qu’il en soit, c’est le fait que les sources soient retouchées pour y coller les patches de stabilité et de sécurité qui fait de debian une distrib fiable, sais tu ? ---
**Author:** ![dimm](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/e9bcb4/32.png) [@dimm](https://www.debian-fr.org/u/dimm)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/4 "2016-02-20T17:35:07Z")
[quote=“mattotop”]Une fois de plus: ce n’est pas une question concernant la programmation, il me semble, non ? [/quote] ![:smt017](https://www.debian-fr.org/uploads/default/original/1X/7bbea83f89515ab7c7a738dddb86c4d4f140bd13.gif)❓ ---
**Author:** ![dimm](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/e9bcb4/32.png) [@dimm](https://www.debian-fr.org/u/dimm)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/5 "2016-02-20T17:35:08Z")
2 articles sur le sujet : [http://chdir.org/~nico//blog/posts/La\_fin\_du\_monde\_\_44\_\_\_OpenSSL\_m\_\_39\_\_a\_tuer…/](http://chdir.org/~nico//blog/posts/La_fin_du_monde __44___ OpenSSL_m __39__ a_tuer.../) [http://chdir.org/~nico//blog/posts/Pire\_que\_je\_croyais…/](http://chdir.org/~nico//blog/posts/Pire_que_je_croyais.../) ---
**Author:** ![dimm](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/e9bcb4/32.png) [@dimm](https://www.debian-fr.org/u/dimm)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/6 "2016-02-20T17:35:08Z")
S’il y a un lien à lire c’est c’est celui-là : [http://www.debian.org/security/key-rollover/](http://www.debian.org/security/key-rollover/) ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/7 "2016-02-20T17:35:08Z")
[quote=“dimm”][quote=“mattotop”]Une fois de plus: ce n’est pas une question concernant la programmation, il me semble, non ?[/quote] ![:smt017](https://www.debian-fr.org/uploads/default/original/1X/7bbea83f89515ab7c7a738dddb86c4d4f140bd13.gif)❓[/quote] Ben oui: si la question etait “comment installer un ssl sans faille ?”, ca serait du support, mais comme ici c’est surtout une “discussion autour d’une faille du paquet openssl”, et qu’on ne se pose même pas la question de corriger le code, quelqu’un a jugé bon de basculer le fil dans pause café, ce qui correspond à ce que je pense de la place de ce fil (d’ou peut être ton incompréhension: à l’origine, le fil était dans “programmation”). En fait, ce n’est pas parcequ’on parle de code source que c’est forcément de la programmation, autrement tout relèverait de la section programmation puisque toute paquet est basé sur du code source. Pour moi, la section programmation ne devrait contenir que des questions autour de la réalisation ou du déboguage d’un bout de code \>actif\<. Je dis ça pour les sujets traitant du latex, PS, et autre PDF qui ne me semblent pas relever de la programmation, même si on peut rentrer dans leur code pour les modifier. AMA, même le HTML ne devrait pas relèver de la programmation, si on me demandais mon avis, bien sûr. Fin bon: je ne sais pas si j’ai été trés clair, là. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/8 "2016-02-20T17:35:17Z")
Avec mes serveurs en sarge, moi ça roule 🙂 ---
**Author:** ![antalgeek1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/a6a055/32.png) [@antalgeek1](https://www.debian-fr.org/u/antalgeek1)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/9 "2016-02-20T17:35:20Z")
> [@](#): > > Avec mes serveurs en sarge, moi ça roule 🙂 la classe ![8)](https://www.debian-fr.org/uploads/default/original/1X/ae031e9834d19166598edd060b063d44f1829139.gif "Cool") ---
**Author:** ![dimm](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/e9bcb4/32.png) [@dimm](https://www.debian-fr.org/u/dimm)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/10 "2016-02-20T17:35:20Z")
@matt : ok j’avais pas vu ce fil dans programmation. ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/11 "2016-02-20T17:35:20Z")
> [@](#): > > Avec mes serveurs en sarge, moi ça roule 🙂 Tu es sûr que ce bug n’affecte que etch et suivantes? Tu peux tester la résistance de tes clés avec ce script perl: [security.debian.org/project/extr … owkd.pl.gz](http://security.debian.org/project/extra/dowkd/dowkd.pl.gz) ```auto ``` ---
**Author:** ![lazone](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/a87d85/32.png) [@lazone](https://www.debian-fr.org/u/lazone)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/12 "2016-02-20T17:35:32Z")
Bonsoir tout le monde. Juste une petite question, si je mesure les problemes qu’une telle faille peut poser sur un serveur, quel est l’impact sur un pc pour une utilisation “classique”? Le paquet ayant ete mis a jour, d’autres manipulations sont elles necessaires pour etre tranquille? Merci pour vos reponses ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/13 "2016-02-20T17:35:34Z")
[quote=“lazone”]Bonsoir tout le monde. Juste une petite question, si je mesure les problemes qu’une telle faille peut poser sur un serveur, quel est l’impact sur un pc pour une utilisation “classique”?[/quote] Bonjour, Aucun sauf si tu utilises un échange de clés pour l’authentification d’une connexion ssh, très pratique pour établir de manière sécurisée une connexion ssh sans mot de passe par exemple. Si tu n’as jamais généré de clés avec ssh-keygen, tu es tranquille. Le bug affecte également les clés VPN et certificats SSL que tu aurais pu générer avec openssl. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/14 "2016-02-20T17:35:35Z")
[quote=“lazone”]Bonsoir tout le monde. Juste une petite question, si je mesure les problemes qu’une telle faille peut poser sur un serveur, quel est l’impact sur un pc pour une utilisation “classique”? Le paquet ayant ete mis a jour, d’autres manipulations sont elles necessaires pour etre tranquille? Merci pour vos reponses[/quote] Coté utilisateur, le seul est l’impact est la connexion à un site en https, si j’ai bien compris, les clefs du machine sont prédictibles et avec un peu de patience il est «facile» (?) de retrouver les clefs d’une machine et de se faire passer pour elle. On peut dans ce cas faire pas mal de chose (escroquerie, …). Dans la pratique, les certificats des machines institutionnelles sont bétons, les récents sont refaits. Sur ta machine personnelle, le plus important est si tu utilises une identification par clef à un serveur et que tes clefs sont récentes, il semble qu’on puisse utiliser un dictionnaire de clefs (un chiffre de 2 heures est avancé pour le temps de craquage je crois bienb). ripat: Je l’avais déjà fait depuis longtemps, pas eu de souci 🙂 Par contre, cela ne fait que tester tes clefs perso, il faudrait en plkus tester les clefs identifiant une machine (dowkd host machine) [quote]$ perl [dowkd.pl](http://dowkd.pl) host stargate # stargate SSH-1.99-OpenSSH\_3.4p1 Debian 1:3.4p1-1.woody.3 # stargate SSH-1.99-OpenSSH\_3.4p1 Debian 1:3.4p1-1.woody.3 summary: keys found: 2, weak keys: 0 $ perl [dowkd.pl](http://dowkd.pl) host cerbere # cerbere SSH-1.99-OpenSSH\_3.8.1p1 Debian-8.sarge.6 # cerbere SSH-1.99-OpenSSH\_3.8.1p1 Debian-8.sarge.6 summary: keys found: 2, weak keys: 0 [/quote] ---
**Author:** ![lazone](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/a87d85/32.png) [@lazone](https://www.debian-fr.org/u/lazone)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/15 "2016-02-20T17:35:35Z")
Merci pour vos explications. ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/16 "2016-02-20T17:35:36Z")
> [@](#): > > Coté utilisateur, le seul est l’impact est la connexion à un site en https, si j’ai bien compris, les clefs du machine sont prédictibles et avec un peu de patience il est «facile» (?) de retrouver les clefs d’une machine et de se faire passer pour elle. On peut dans ce cas faire pas mal de chose (escroquerie, …). Dans la pratique, les certificats des machines institutionnelles sont bétons, les récents sont refaits. Le certificat SSL stocké sur une machine client est un peu comme la clé publique d’un serveur non? Du coup, si le certificat (clé privée sur serveur web et clé publique sur la machine client), a été produit par la version boguée d’openssl, le webmaster du site https doit changer le certificat (clé privée _et_ clé publique). L’utilisateur n’a rien a faire d’autre qu’espérer que le webmaster est consciencieux et lui renvoie un nouveau certificat si nécessaire. > [@](#): > > ripat: Je l’avais déjà fait depuis longtemps, pas eu de souci 🙂 Par contre, cela ne fait que tester tes clefs perso, il faudrait en plkus tester les clefs identifiant une machine (dowkd host machine) Je n’avais pas songé à ça. J’ai testé sur mes serveurs et il y en a un qui n’a pas reconstruit ses clés “host” lors de la mise à niveau d’openssh. C’est quoi la commande pour refaire les clés ssh\_host\_\*\_key? Ou bien je dois reconfigurer openssh (dpkg-reconfigure?) Edit: J’ai touvé. [code]# ssh-keygen -t rsa -f /etc/ssh/ssh\_host\_rsa\_key # ssh-keygen -t dsa -f /etc/ssh/ssh\_host\_dsa\_key[/code][dowkd.pl](http://dowkd.pl) ne râle plus maintenant. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/17 "2016-02-20T17:35:37Z")
> [@](#): > > Le certificat SSL stocké sur une machine client est un peu comme la clé publique d’un serveur non? Du coup, si le certificat (clé privée sur serveur web et clé publique sur la machine client), a été produit par la version boguée d’openssl, le webmaster du site https doit changer le certificat (clé privée _et_ clé publique). > [/quote]Le certificat sert à identifier le serveur. La machine cleint vérifie que le serveur est bien la machine voulue. Pour cela en gros, elle demande au serveur de coder un message donné et le décode à l’aide de la clef punlique. Si elle retrouve le message, la machine est considérée comme sûre. Par la suite, les clefs permettent d’échanger une clef > classique très longue permettant de faire un dialogue rapidement. > Peut être que le bug intervient aussi dans la fabrication de cette deuxième clef (aspect prédictible) mais ça m’étonnerait. > La machine client, elle, ne s’identifie pas auprès du serveur (sauf par exemple pour les impôts avec un dispositif de certificats «spécial impot». Les librairies ne servent pas de ce coté. > > > [@](#): > > > > ripat: Je l’avais déjà fait depuis longtemps, pas eu de souci 🙂 Par contre, cela ne fait que tester tes clefs perso, il faudrait en plkus tester les clefs identifiant une machine (dowkd host machine) > > Je n’avais pas songé à ça. J’ai testé sur mes serveurs et il y en a un qui n’a pas reconstruit ses clés “host” lors de la mise à niveau d’openssh. C’est quoi la commande pour refaire les clés ssh\_host\_\*\_key? Ou bien je dois reconfigurer openssh (dpkg-reconfigure?) > > Edit: J’ai touvé. > > [code]# ssh-keygen -t rsa -f /etc/ssh/ssh\_host\_rsa\_key > > # ssh-keygen -t dsa -f /etc/ssh/ssh\_host\_dsa\_key[/code][dowkd.pl](http://dowkd.pl) ne râle plus maintenant.[/quote] > > C’est ça qui est le plus important. C’est par ce biais qu’une attaque «man in the meeddle» serait possible. > edit: Encore que Raphael Hertzog a signalé l’existence de scripts déjà actifs: > > [quote=“Raphael Hertzog sur la DUF”]C’est que ta clé publique est “blacklistée” par la récente mise à jour de > sécurité. Ta paire de clé n’est pas fiable car générée avec une version de > la bibliothèque openssl défectueuse (et toutes ces mauvaises clés > circulent dans la nature et sont déjà employée par des script-kiddies pour > essayer d’accéder à vos comptes SSH, il est impératif que tous les > utilisateurs qui ont installé des mauvaises clés SSH dans des > .ssh/authorized\_keys les enlèvent partout et surtout sur les serveurs > non-Debian qui n’ont pas la mise à jour de sécurité qui blackliste ces > clés!) PS: Je serais très flatté qu’un gars essaye de me faire une attaque man in the meeddle entre moi et une de mes serveurs 🙂 ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/18 "2016-02-20T17:35:37Z")
> [@](#): > > [quote=“Raphael Hertzog sur la DUF”]C’est que ta clé publique est “blacklistée” par la récente mise à jour de > sécurité. Ta paire de clé n’est pas fiable car générée avec une version de > la bibliothèque openssl défectueuse (et toutes ces mauvaises clés > circulent dans la nature et sont déjà employée par des script-kiddies pour > essayer d’accéder à vos comptes SSH, il est impératif que tous les > utilisateurs qui ont installé des mauvaises clés SSH dans des > .ssh/authorized\_keys les enlèvent partout et surtout sur les serveurs > non-Debian qui n’ont pas la mise à jour de sécurité qui blackliste ces > clés!) PS: Je serais très flatté qu’un gars essaye de me faire une attaque man in the meeddle entre moi et une de mes serveurs 🙂[/quote] C’est quoi cette mise à jour de sécurité qui blackliste automatiquement les clés faibles? Jamais entendu parler. Juste après ma mise à niveau et _avant_ de refaire mes clés, je n’ai eu aucun problème pour me connecter avec mes anciennes clés vérolées. ---
**Author:** ![antalgeek1](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/a6a055/32.png) [@antalgeek1](https://www.debian-fr.org/u/antalgeek1)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/19 "2016-02-20T17:35:37Z")
Moi j’ai eu le cas hier après-midi : pas moyen de joindre mon serveur ouebe maison depuis le boutot par clé, ça basculait sur mot de passe. Mon ancienne clé crado est blacklistée (voir dans /etc/ssh/) et une ligne apparaît dans auth.log. ---
**Author:** ![ripat](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/bc79bd/32.png) [@ripat](https://www.debian-fr.org/u/ripat)\ **Post date:** [Février 20, 2016, 5:35 UTC](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764/20 "2016-02-20T17:35:38Z")
Ah, oui, il y a effectivement deux blacklists dans /etc/ssh: /etc/ssh/blacklist.DSA-1024 /etc/ssh/blacklist.RSA-2048 et ils datent de ma mise à niveau. Voir aussi: man ssh-vulnkey Pas mal tout de même la sécurité debian. On fait une bêtise mais on s’en protège efficacement. Bon, il aurait mieux valu ne pas boguer oppenssl mais personne n’est infaillible… [Page suivante](https://www.debian-fr.org/t/packahe-openssl-debian-vulnerable/13764.md?page=2)