Important : faille OpenSSL sur distribs Debian 4 (Etch)

[LeMulotNocturne]

Bonjour à tous,

désolé si l'info a déjà été postée, mais il vaut mieux enfoncer le clou pour ceux qui ont des serveurs dédiés sous Debian 4 et qui font du SSL (SSH, https, etc...). A priori, les vielles versions de Debian (3.1 par ex.) ne sont pas affectées.

http://linuxfr.org/2008/05/15/24092.html

:!: Soyez particulirement vigilents si votre accès SSH se fait par clef SSL et non pas par password.

 

[Julia41]

L'exploit consiste à générer toutes les clés pour le login qui sont normalement aléatoire mais qui sur la version ETCH ont été généré avec un randomn non randomn, et donc ne sont pas aléatoire.

Sous SID, ils ont sorti un petit tool pour voir si vos systèmes sont sensibles ou non, à partir d'une blacklist de fingerprint...

ssh-keyscan -t rsa,dsa -p 22 <IP> | ssh-vulney -

Sur webrankinfo par exemple, depuis ce matin c'est corrigé :

gd09:~# ssh-keyscan -t rsa,dsa -p 22 www.webrankinfo.com | ssh-vulnkey -
# www.webrankinfo.com SSH-2.0-OpenSSH_xx Debian-xetch1
# www.webrankinfo.com SSH-2.0-OpenSSH_xx Debian-xetch1
Not blacklisted: 1024 XX:65:53:35:27:6c:c8:f4:29:bd:82:XX:76:e4:72:22 www.webrankinfo.com
Not blacklisted: 2048 XX:65:ae:8d:56:3e:f0:18:d1:4e:06:XX:24:ad:1b:93 www.webrankinfo.com

Edit : exemple de clés compromises :

gd09:~# ssh-keyscan -t rsa,dsa -p 22 XXX.com | ssh-vulnkey -
# XXX.com SSH-2.0-OpenSSH_4.3p2 Debian-9
# XXX.com SSH-2.0-OpenSSH_4.3p2 Debian-9
COMPROMISED: 1024 b4:ae:d4:6b:66:9a:b8:b6:2d:ab:91:04:a4:92:06:61 XXX.com
COMPROMISED: 2048 e9:69:a8:b3:4d:3b:23:fa:a4:44:8d:bf:58:26:6f:e3 XXX.com

C'est plutôt urgent et je vous conseille de bien tester votre système...
Les clés OVH ont un from, il y a donc aucun risque pour ce genre de chose.

 

[pierre_jean]

merci pour l'info.

ou trouver l'outil ssh-vulnkey ?

Edit :

pensez à faire un update avant d'installer les paquets blacklist

merci

 

[Ron56]

Moi jvais me renseigner sur les systèmes BSD

 

[jcaron]

Bonjour à tous,

désolé si l'info a déjà été postée, mais il vaut mieux enfoncer le clou pour ceux qui ont des serveurs dédiés sous Debian 4 et qui font du SSL (SSH, https, etc...). A priori, les vielles versions de Debian (3.1 par ex.) ne sont pas affectées.

http://linuxfr.org/2008/05/15/24092.html

:!: Soyez particulirement vigilents si votre accès SSH se fait par clef SSL et non pas par password.

Attention: le problème est visiblement nettement pire que ça: tout serveur (quel que soit l'OS) qui a des clefs qui ont été générées sur une Debian (ou dérivé genre Ubuntu...) affectée (toutes les versions depuis 2 ans!) est vulnérable (à divers degrés bien entendu).

En particulier tout serveur SSH avec des "authorized_keys" générées sur ces machines permet de se connecter comme l'utilisateur qui a installé cette clef.

Pas cool.

Jacques.

 

[LeMulotNocturne]

Attention: le problème est visiblement nettement pire que ça: tout serveur (quel que soit l'OS) qui a des clefs qui ont été générées sur une Debian (ou dérivé genre Ubuntu...) affectée (toutes les versions depuis 2 ans!) est vulnérable (à divers degrés bien entendu).

En particulier tout serveur SSH avec des "authorized_keys" générées sur ces machines permet de se connecter comme l'utilisateur qui a installé cette clef.

oui, absolument tu as raison de me rectifier !
C'est bien la galère ce truc là...

 

[Ohax]

La commande est fausse, c'est

ssh-keyscan -t rsa,dsa -p 22 <IP> | ssh-vulnkey -

 

[Julia41]

La commande est fausse, c'est

ssh-keyscan -t rsa,dsa -p 22 <IP> | ssh-vulnkey -

Que ferait-on pas pour augmenter son nombre de post ^^

En passant, l'exploit commence à bien circuler donc mettez à jour ^^

 

[Monty973]

... normalement aléatoire mais qui sur la version ETCH ont été généré avec un randomn non randomn, et donc ne sont pas aléatoire.

^^

 

[Julia41]

... normalement aléatoire mais qui sur la version ETCH ont été généré avec un randomn non randomn, et donc ne sont pas aléatoire.

^^

Ca fait 2 ! :arrow:

 

[colonies]

dans le même genre :

 

[2dm]

Ca fait 2 !

Ce qui est le nombre de ligne modifié dans le patch qui a causé le problème.
Ce qui est tout de même étonnant.

Si la modification de deux lignes par un contributeur n'est pas vérifié, alors on peut se demander quelles sont les contributions qui le sont véritablement.