Packahe OpenSSL Debian vulnérable

Pause Café
#1

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/
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…

#2

J’ai suivi l’affaire :wink: :
http://forum.debian-fr.org/viewtopic.php?f=1&t=14173

#3

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 ?

#4

[quote=“mattotop”]Une fois de plus: ce n’est pas une question concernant la programmation, il me semble, non ?
[/quote] :smt017 :question:

#5

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/Pire_que_je_croyais…/

#6

S’il y a un lien à lire c’est c’est celui-là : http://www.debian.org/security/key-rollover/

#7

[quote=“dimm”][quote=“mattotop”]Une fois de plus: ce n’est pas une question concernant la programmation, il me semble, non ?[/quote] :smt017 :question:[/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à.

#8

Avec mes serveurs en sarge, moi ça roule :slightly_smiling:

#9

la classe 8)

#10

@matt : ok j’avais pas vu ce fil dans programmation.

#11

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

#12

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

#13

[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.

#14

[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 :slightly_smiling: 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 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 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]

#15

Merci pour vos explications.

#16

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.

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 ne râle plus maintenant.

#17

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 :slightly_smiling:

#18

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 :slightly_smiling:[/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.

#19

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.

#20

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…