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?
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. :-)
"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/
la source