O Heartbleed afeta as chaves ssh?

Question

O bug Heartbleed recente afeta as chaves ssh que eu criei e usa para empurrar / puxar código com o Github, Heroku e outros sites similares?

Preciso substituir as chaves que estou usando?

    

Answer 1

Não, o Heartbleed realmente não afeta as chaves SSH, então você provavelmente não precisa substituir as chaves SSH que você está usando.

Primeiro, SSL e SSH são dois protocolos de segurança diferentes para dois usos diferentes. Da mesma forma, o OpenSSL e o OpenSSH também são dois pacotes de software completamente diferentes, apesar das semelhanças em seus nomes.

Em segundo lugar, a exploração Heartbleed faz com que o peer TLS / DTLS do OpenSSL vulnerável retorne uma memória aleatória de 64kB, mas é quase certamente limitado à memória acessível àquele processo que usa o OpenSSL. Se esse processo de uso do OpenSSL não tiver acesso à sua chave privada SSH, ele não poderá vazá-lo via Heartbleed.

Além disso, você normalmente só coloca a chave pública do SSH nos servidores nos quais você usa o SSH, e como o nome indica, uma chave pública é uma chave que você pode divulgar. Não importa quem sabe. De fato, você quer que o público saiba sua chave pública correta.

Obrigado ao @Bob por apontar que a vulnerabilidade pode afetar os 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 estivesse conectado a um servidor mal-intencionado, esse servidor mal-intencionado poderia usar o Heartbleed para ver fragmentos aleatórios da memória desse software cliente. Se, por algum motivo, esse aplicativo cliente tiver uma cópia de suas chaves privadas SSH na memória, ele poderá vazar via Heartbleed.

Na minha cabeça, 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 no disco. Se você não mantiver suas chaves privadas SSH criptografadas em disco, então você pode ter usado algum programa de backup ou de transferência de arquivos OpenSSL TLS para copiar ou fazer backup do seu diretório home pela rede (incluindo seu ~/.ssh/id_rsa ou outro Chave privada SSH), então ele pode ter uma cópia não criptografada de sua chave privada SSH na memória. Então, novamente, se você estivesse fazendo o backup de sua chave privada SSH não criptografada em um servidor mal-intencionado, provavelmente teria preocupações maiores do que o Heartbleed. : -)

    

Answer 2

"Segundo, o exploit Heartbleed faz com que o par TLS / DTLS do OpenSSL vulnerável retorne 64kB aleatoriamente de memória, mas é quase certamente limitado à memória acessível àquele processo que usa o OpenSSL."

se a máquina for comprometida, como você pode confiar em qualquer coisa, incluindo o ssh? de heartbleed.com

" O que vaza na prática?

Testamos alguns dos nossos próprios serviços do ponto de vista do atacante. Nós nos atacamos de fora, sem deixar vestígios. Sem o uso de qualquer informação privilegiada ou credenciais, conseguimos roubar de nós mesmos as chaves secretas usadas para nossos certificados X.509, nomes de usuário e senhas, mensagens instantâneas, e-mails e documentos críticos de negócios e comunicação. "

alguém pode ter colocado uma chave privada, sem senha, em um servidor que eles achavam que não era malicioso ... mas acabou sendo. bug b / c SSL permitiu a saída de um usuário, um usuário que tinha 'sudo' ... provavelmente não é um problema .... mas ...

as pessoas fazem coisas malucas às vezes

link