¿El reciente error de Heartbleed afecta las claves ssh que he generado y uso para insertar / extraer código con Github, Heroku y otros sitios similares?
¿Necesito reemplazar las llaves que he estado usando?
¿El reciente error de Heartbleed afecta las claves ssh que he generado y uso para insertar / extraer código con Github, Heroku y otros sitios similares?
¿Necesito reemplazar las llaves que he estado usando?
Respuestas:
No, Heartbleed realmente no afecta las claves SSH, por lo que probablemente no necesite reemplazar las claves SSH que ha estado utilizando.
Primero, SSL y SSH son dos protocolos de seguridad diferentes para dos usos diferentes. Del mismo modo, OpenSSL y OpenSSH también son dos paquetes de software completamente diferentes, a pesar de las similitudes en sus nombres.
En segundo lugar, el exploit Heartbleed hace que los pares vulnerables OpenSSL TLS / DTLS devuelvan una memoria aleatoria de 64kB, pero es casi seguro que se limite a la memoria accesible para ese proceso que usa OpenSSL. Si ese proceso que usa OpenSSL no tiene acceso a su clave privada SSH, entonces no puede filtrarse a través de Heartbleed.
Además, normalmente solo coloca su clave pública SSH en los servidores a los que usa SSH para conectarse y, como su nombre lo indica, una clave pública es una clave que puede publicitar. No importa quién lo sepa. De hecho, desea que el público conozca su clave pública correcta.
Gracias a @Bob por señalar que la vulnerabilidad puede afectar a las aplicaciones cliente que usan versiones vulnerables de OpenSSL como su biblioteca TLS / DTLS del lado del cliente. Entonces, si, por ejemplo, su navegador web o su cliente VPN basado en SSL utilizó una versión vulnerable de OpenSSL y se conectó a un servidor malicioso, ese servidor malicioso podría usar Heartbleed para ver fragmentos aleatorios de la memoria del software de ese cliente. Si esa aplicación cliente por alguna razón tuviera una copia de sus claves privadas SSH en la memoria, entonces podría filtrarse a través de Heartbleed.
Fuera de mi cabeza, no estoy pensando en ningún software además de SSH que pueda tener una copia de su clave privada SSH sin cifrar en la memoria. Bueno, eso supone que mantiene sus claves privadas SSH encriptadas en el disco. Si no mantiene sus claves privadas SSH encriptadas en el disco, entonces supongo que podría haber utilizado algún programa de transferencia de archivos o copia de seguridad usando OpenSSL TLS para copiar o hacer una copia de seguridad de su directorio principal a través de la red (incluida su ~/.ssh/id_rsau otra clave privada SSH ), entonces podría tener una copia sin cifrar de su clave privada SSH en la memoria. Por otra parte, si estaba haciendo una copia de seguridad de su clave privada SSH sin cifrar en un servidor malicioso, probablemente tenga mayores preocupaciones que Heartbleed. :-)
"En segundo lugar, el exploit Heartbleed hace que los pares vulnerables de OpenSSL TLS / DTLS devuelvan una memoria aleatoria de 64kB, pero es casi seguro que se limita a la memoria accesible para ese proceso que usa OpenSSL".
Si la máquina se ve comprometida, ¿cómo puede confiar en algo, incluida ssh? de heartbleed.com
"¿Qué se pierde en la práctica?
Hemos probado algunos de nuestros propios servicios desde la perspectiva del atacante. Nos atacamos desde afuera, sin dejar rastro. Sin usar ninguna información o credenciales privilegiadas, pudimos robarnos las claves secretas utilizadas para nuestros certificados X.509, nombres de usuario y contraseñas, mensajes instantáneos, correos electrónicos y documentos y comunicaciones críticos para el negocio. "
alguien podría haber puesto una clave privada, sin frase de contraseña, en un servidor que supuso que no era malicioso ... pero resultó ser. El error SSL de b / c permitió la contraseña de un usuario, un usuario que tenía 'sudo' ... probablemente no sea un problema ... pero ...
la gente hace cosas locas a veces
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/