Heartbleed affecte-t-il les clés SSH?

40

Le récent bogue Heartbleed affecte-t-il les clés ssh que j'ai générées et utilisées pour pousser / extraire du code avec Github, Heroku et d'autres sites similaires?

Dois-je remplacer les clés que j'ai utilisées?

ssh openssl heartbleed

— LikeMaBell
source

47

Non, Heartbleed n’affecte pas vraiment les clés SSH, vous n’avez donc probablement pas besoin de remplacer les clés SSH que vous utilisez.

Premièrement, SSL et SSH sont deux protocoles de sécurité différents pour deux utilisations différentes. De même, OpenSSL et OpenSSH sont également deux progiciels complètement différents, malgré les similitudes dans leurs noms.

Deuxièmement, l’exploit Heartbleed force l’homologue OpenSSL TLS / DTLS vulnérable à restituer une mémoire aléatoire de 64 Ko, mais il est presque certainement limité à la mémoire accessible pour ce processus utilisant OpenSSL. Si ce processus utilisant OpenSSL n'a pas accès à votre clé privée SSH, il ne peut pas la divulguer via Heartbleed.

En outre, vous ne placez généralement votre clé publique SSH que sur les serveurs auxquels vous utilisez SSH pour vous connecter. Comme son nom l'indique, une clé publique est une clé que vous pouvez publier. Peu importe qui le sait. En fait, vous voulez que le public connaisse votre clé publique correcte.

Merci à @Bob pour avoir signalé que cette vulnérabilité peut affecter les applications clientes qui utilisent des versions vulnérables d'OpenSSL en tant que bibliothèque TLS / DTLS côté client. Ainsi, par exemple, si votre navigateur Web ou votre client VPN basé sur SSL utilisait une version vulnérable d'OpenSSL et était connecté à un serveur malveillant, ce serveur malveillant pourrait utiliser Heartbleed pour afficher des extraits aléatoires de la mémoire de ce logiciel client. Si, pour une raison quelconque, cette application cliente avait une copie de vos clés privées SSH en mémoire, elle pourrait alors fuir via Heartbleed.

En tête, je ne pense à aucun logiciel, à part SSH, qui pourrait avoir une copie de votre clé privée SSH non chiffrée en mémoire. Cela suppose que vous gardiez vos clés privées SSH chiffrées sur le disque. Si vous ne conservez pas vos clés privées SSH chiffrées sur le disque, vous auriez peut-être utilisé un programme de transfert de fichier ou de sauvegarde utilisant OpenSSL TLS pour copier ou sauvegarder votre répertoire personnel sur le réseau (y compris votre ~/.ssh/id_rsaclé privée SSH ou autre). ), alors il pourrait avoir une copie non chiffrée de votre clé privée SSH en mémoire. Encore une fois, si vous sauvegardiez votre clé privée SSH non chiffrée sur un serveur malveillant, vous avez probablement de plus gros soucis que Heartbleed. :-)

— Spiff
source

3

Notez que les commentaires du public ne sont vraiment pas pertinents - Heartbleed affecte à la fois les clients et les serveurs. Mais vous avez raison de dire que SSH est différent et n'est pas affecté par cette vulnérabilité particulière .

— Bob

1

@Bob Merci, les publications de Heartbleed ont été tellement centrées sur le serveur que je n'avais pas compris les ramifications côté client. J'ai mis à jour ma réponse pour mieux répondre à cela. Je pense toujours qu'il est très peu probable que des personnes aient laissé une clé privée SSH à un endroit où un processus vulnérable de Heartbleed pourrait être en mesure de la divulguer.

— Spiff

1

Il convient de mentionner que SSH utilise la bibliothèque OpenSSL pour le chiffrement. Comme vous l'avez fait remarquer, ssh n'est toutefois pas concerné par cet exploit car il s'agit d'un protocole différent.

— psibar

1

"Deuxièmement, l'exploit Heartbleed force l'homologue vulnérable OpenSSL TLS / DTLS à restituer une mémoire aléatoire de 64 Ko, mais il est presque certainement limité à la mémoire accessible au processus utilisant OpenSSL."

si la machine est compromise alors comment pouvez-vous faire confiance à quoi que ce soit, y compris ssh? de heartbleed.com

"Quelles fuites dans la pratique?

Nous avons testé certains de nos propres services du point de vue de l'attaquant. Nous nous sommes attaqués de l'extérieur, sans laisser de traces. Sans utiliser d'informations ni d'informations d'identification privilégiées, nous avons pu nous voler les clés secrètes utilisées pour nos certificats X.509, noms d'utilisateur et mots de passe, messages instantanés, courriers électroniques, documents stratégiques et la communication. "

Quelqu'un aurait pu mettre une clé privée, sans mot de passe, sur un serveur dont il pensait qu'il n'était pas malveillant ... mais qui s'est avéré être. b / c SSL bug autorisait la sortie du mot de passe d'un utilisateur, un utilisateur qui avait 'sudo' ... ce n'est probablement pas un problème ... mais ...

les gens font des trucs fous parfois

http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/

— don lumineux
source

Je pense que cette citation fait référence à un homme au milieu d'une attaque utilisant les clés TLS volées. Un attaquant ne devrait pas pouvoir accéder à la mémoire depuis d'autres programmes, sinon cela mettrait en évidence un problème de sécurité du système d'exploitation.

— Matthew Mitchell

Si un utilisateur a mis sa clé SSH privée non chiffrée sur des serveurs, il ne peut pas nous aider. Envoyez-lui un lien vers piv.pivpiv.dk .

— Spiff