O bug recente do Heartbleed afeta as teclas ssh que eu gerei e as utilizo para enviar / receber códigos com o Github, Heroku e outros sites semelhantes?
Preciso substituir as chaves que estou usando?
O bug recente do Heartbleed afeta as teclas ssh que eu gerei e as utilizo para enviar / receber códigos com o Github, Heroku e outros sites semelhantes?
Preciso substituir as chaves que estou usando?
Respostas:
Não, o Heartbleed realmente não afeta as chaves SSH, portanto você provavelmente não precisa substituir as chaves SSH que está usando.
Primeiro, SSL e SSH são dois protocolos de segurança diferentes para dois usos diferentes. Da mesma forma, OpenSSL e OpenSSH também são dois pacotes de software completamente diferentes, apesar das semelhanças em seus nomes.
Segundo, a exploração do Heartbleed faz com que o vulnerável OpenSSL TLS / DTLS peer retorne 64kB aleatórios de memória, mas é quase certamente limitado à memória acessível ao processo de uso do OpenSSL. Se esse processo de uso do OpenSSL não tiver acesso à sua chave privada SSH, não será possível vazá-lo pelo Heartbleed.
Além disso, você normalmente coloca sua chave pública SSH apenas nos servidores aos quais usa o SSH para se conectar e, como o nome indica, uma chave pública é uma chave que você pode divulgar. Não importa quem sabe. De fato, você deseja que o público conheça sua chave pública correta.
Agradecemos ao @Bob por apontar que a vulnerabilidade pode afetar aplicativos clientes que usam versões vulneráveis do OpenSSL como sua biblioteca TLS / DTLS do lado do cliente. Portanto, se, por exemplo, seu navegador da Web ou seu cliente VPN baseado em SSL usasse uma versão vulnerável do OpenSSL e conectado a um servidor mal-intencionado, esse servidor mal-intencionado poderia usar o Heartbleed para ver trechos aleatórios da memória do software cliente. Se, por algum motivo, esse aplicativo cliente tiver uma cópia de suas chaves privadas SSH na memória, poderá vazar pelo Heartbleed.
Em primeiro lugar, não estou pensando em nenhum software além do SSH que possa ter uma cópia da sua chave privada SSH não criptografada na memória. Bem, isso pressupõe que você mantenha suas chaves privadas SSH criptografadas em disco. Se você não mantiver suas chaves privadas SSH criptografadas em disco, suponho que você possa ter usado algum programa de transferência ou backup de arquivos usando OpenSSL TLS para copiar ou fazer backup de seu diretório pessoal pela rede (incluindo sua ~/.ssh/id_rsaou outra chave privada SSH ), pode haver uma cópia não criptografada da sua chave privada SSH na memória. Por outro lado, se você estava fazendo backup da sua chave privada SSH não criptografada em um servidor mal-intencionado, provavelmente terá maiores preocupações do que o Heartbleed. :-)
"Segundo, a exploração do Heartbleed faz com que o vulnerável OpenSSL TLS / DTLS peer retorne 64kB aleatórios de memória, mas é quase certamente limitado à memória acessível ao processo de uso do OpenSSL".
se a máquina ficar comprometida, como você pode confiar em algo, incluindo ssh? de heartbleed.com
"O que vaza na prática?
Testamos alguns de nossos próprios serviços da perspectiva do invasor. Nos atacamos do lado de fora, sem deixar vestígios. Sem usar informações ou credenciais privilegiadas, fomos capazes de roubar de nós as chaves secretas usadas para nossos certificados X.509, nomes de usuário e senhas, mensagens instantâneas, e-mails e documentos e comunicações essenciais aos negócios. "
alguém pode ter colocado uma chave privada, sem senha, em um servidor que eles supunham que não era malicioso ... mas acabou sendo. b / c bug SSL permitiu a saída de uma senha de usuário, um usuário que tinha 'sudo' ... provavelmente não é um problema .... mas ...
as pessoas fazem coisas loucas às vezes
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/