Encore une fois : ce n'est pas parce qu'une machine utilise une distribution qui n'est pas une dérivée Debian, ou n'a pas inclus la version saccagée d'openssl, que cette machine est à l'abri. Il suffit qu'un utilisateur de la machine y ai placé une clef ssh vérolée (générée sur une Gutsy, par exemple) pour que la machine soit compromise.
En fait, si j'ai bien compris, c'est l'inverse.
Si une paire de clefs DSA a été générée sur une machine saine mais que la clef privée a été utilisée sur une machine avec l'openssl impacté, alors cette clef et vulnérable.
En effet, l'algorithme de DSA utilise des nombres aléatoires pour la signature et avec plusieurs messages signés avec l'openssl impacté il y a un risque de pouvoir retrouver la clef privé.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Yannick . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
En fait, si j'ai bien compris, c'est l'inverse.
Si une paire de clefs DSA a été générée sur une machine saine mais que la clef privée a été utilisée sur une machine avec l'openssl impacté, alors cette clef et vulnérable.
En effet, l'algorithme de DSA utilise des nombres aléatoires pour la signature et avec plusieurs messages signés avec l'openssl impacté il y a un risque de pouvoir retrouver la clef privé.