Est-ce que le récent bug Heartbleed affecte les clés ssh que j'ai générées et que j'utilise pour pousser/tirer du code avec Github, Heroku et d'autres sites similaires?
Est-ce que je dois remplacer les clés que j'utilise actuellement?
Réponses
Trop de publicités?
Non, Heartbleed n'affecte pas vraiment les clés SSH, donc vous n'avez 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 packages logiciels complètement différents, malgré les similitudes dans leurs noms.
Deuxièmement, l'exploit Heartbleed fait en sorte que le pair TLS/DTLS OpenSSL vulnérable retourne une mémoire aléatoire de 64 ko, mais il est presque certainement limité à la mémoire accessible à ce processus utilisant OpenSSL. Si ce processus utilisant OpenSSL n'a pas accès à votre clé privée SSH, alors il ne peut pas la divulguer via Heartbleed.
De plus, vous mettez généralement seulement votre clé publique SSH sur les serveurs auxquels vous vous connectez en SSH, et comme son nom l'indique, une clé publique est une clé que vous pouvez rendre publique. Peu importe qui la connaît. En fait, vous voulez que le public connaisse votre clé publique correcte.
Merci à @Bob d'avoir souligné que la vulnérabilité peut affecter les applications clientes qui utilisent des versions vulnérables d'OpenSSL comme leur bibliothèque TLS/DTLS côté client. Donc, si, par exemple, votre navigateur web ou votre client VPN basé sur SSL utilisait une version vulnérable d'OpenSSL et se connectait à un serveur malveillant, ce dernier pourrait utiliser Heartbleed pour voir des extraits aléatoires de la mémoire de ce logiciel client. Si cette application cliente avait pour une raison quelconque une copie de vos clés privées SSH en mémoire, alors cela pourrait fuiter via Heartbleed.
Off the top of my head, je ne pense à aucun logiciel autre que SSH qui pourrait avoir une copie de votre clé privée SSH non chiffrée en mémoire. Eh bien, cela suppose que vous gardez vos clés privées SSH chiffrées sur disque. Si vous ne gardez pas vos clés privées SSH chiffrées sur disque, alors je suppose que vous pourriez avoir utilisé un programme de transfert de fichiers ou de sauvegarde utilisant TLS d'OpenSSL pour copier ou sauvegarder votre répertoire personnel sur le réseau (y compris votre ~/.ssh/id_rsa ou autre clé privée SSH), alors il pourrait avoir une copie non chiffrée de votre clé privée SSH en mémoire. Encore une fois, si vous faisiez une sauvegarde de votre clé privée SSH non chiffrée sur un serveur malveillant, vous avez probablement des soucis plus importants que Heartbleed. :-)
Gaurav Rathi
Points
11
"Deuxièmement, l'exploitation de Heartbleed fait en sorte que le pair vulnérable OpenSSL TLS/DTLS retourne aléatoirement 64ko de mémoire, mais il est presque certainement limité à la mémoire accessible par ce processus utilisant OpenSSL. "
si la machine est compromise alors comment pouvez-vous avoir confiance en quoi que ce soit dessus, y compris ssh? de heartbleed.com
" Quelles fuites sont pratiques?
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 trace. Sans utiliser d'informations ou de privilèges, nous avons pu nous voler les clés secrètes utilisées pour nos certificats X.509, les noms d'utilisateur et les mots de passe, les messages instantanés, les e-mails et les documents et communications critiques pour les entreprises. "
quelqu'un a peut-être mis une clé privée, sans phrase secrète, sur un serveur qu'il pensait non malveillant... mais qui s'est avéré l'être. parce que le bug SSL a permis de sortir le mot de passe d'un utilisateur, un utilisateur qui avait 'sudo'... ce n'est probablement pas un problème... mais...
les gens font parfois des choses folles
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/
