9

So I'm getting conflicting information from members of my team. The premise is, if an attacker can keep requesting 64 kb chunks of memory from my server, they could get the entire memory footprint of my server, and thus get the private key I used out of memory.

So, is the private SSH key I used to log in stored in memory? Do I have to worry about my SSH keys?

TerminalDilettante
  • 191
  • 1
  • 4
  • 1
    It's worth reading this: http://security.stackexchange.com/questions/55119/does-the-heartbleed-vulnerability-affect-clients-as-severely?rq=1 – Polynomial Apr 09 '14 at 20:32
  • Thanks. Definitely gave me more background, but still need an answer to the original question. (I'm connecting from Windows machines with PuTTy to machines we control so I believe we're safe there) – TerminalDilettante Apr 09 '14 at 20:40
  • OpenSSL and OpenSSH are different libraries. OpenSSH isn't affected, and although OpenSSH relies on OpenSSL to varying degrees, no, your SSH connections are not vulnerable. (At least to my knowledge). – David W Apr 09 '14 at 20:51
  • 1
    SSH private keys are not stored by the webserver, in that case I think that [Can Heartbleed be used to obtain memory from other processes?](http://security.stackexchange.com/q/55097/2630) should answer your question. – Lekensteyn Apr 09 '14 at 21:06
  • 2
    See also http://security.stackexchange.com/q/55217/33 – AviD Apr 10 '14 at 21:30
  • Note: re-opened for relative importance and uniqueness. Kind of a dupe, but one I consider worthy since "kind of". – Jeff Ferland Apr 11 '14 at 00:33

4 Answers4

12

No. OpenSSH uses a very limited subset of the OpenSSL library, and that subset does not include the code involved in the Heartbleed vulnerability (or any of the other SSL/TLS code, for that matter).

Additionally, the Heartbleed vulnerability doesn't permit an application to read memory outside of its address space, so, for example, a vulnerable web server can't reach out and grab keys from a SSH server.

Mark
  • 34,390
  • 9
  • 85
  • 134
5

It cannot be repeated enough :-)

No But! If you run any other services on the host machine, OpenVPN for instance, wich uses OpenSSL, its vulnerable and can be exploited.

Neophyte
  • 339
  • 1
  • 4
  • Interesting note--our OpenVPN uses it's own static library for SSL so we were actually safe in that regard. – TerminalDilettante Apr 10 '14 at 13:14
  • 1
    Follow up: OpenVPN basically "lied" about which version of SSL it was using (someone changed the filename to make it seem like it was using an older version) and the vulnerability was discovered using a tool. We were not happy campers that night. – TerminalDilettante Apr 30 '14 at 19:49
3

When you log in with SSH, your client has the private key, and the server has the public key. Therefore, no vulnerability on the server can leak your private key, since the server doesn't have it.

The server cannot use Heartbleed to get the private key from your client, since that's an SSH implementation, and only OpenSSL SSL/TLS connections on version 1.0.1 to 1.0.1f are vulnerable. No other implementations of any type at all have this issue, including all SSH implementations.

Now, if the server has its own private SSH keys in memory somewhere, then deeper investigation would be called for.... but it would be cheaper to fix the vulnerability and then regenerate the server's SSH key pair, since there's no Certificate Authority to pay to sign SSH keys!

Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • So to be clear, the server never gets the private key? So what is the mechanism of authentication, then? – TerminalDilettante Apr 10 '14 at 13:14
  • 2
    @TerminalDilettante When your authenticating with SSH keys your private key isn’t sent, the server sends you some random data and challenges your client to encrypt it with your private key. It then verifies the encrypted data by decrypting it with the public key and checking if it matches the data originally sent. – phixr Apr 10 '14 at 21:02
  • Thank you! I was having trouble understanding that handshake process. – TerminalDilettante Apr 12 '14 at 04:44
1

Generally no, but it depends on how paranoid you are, and on the specifics of the vulnerable system.

Like others have said, openssh keys cannot be directly leaked by a heart-bleeding openssl server. But if information is leaked (like say an https user login) then perhaps an attacker could use that password to gain access to the system. From there, your user ssh private key is safe if it's not on the local file system. But if the attacker uses that information to gain root access a lot more trouble happens (of course). For example, they could now decrypt your ssh traffic and if you had an ssh agent enabled on the system, the attacker could now ssh to other systems as you, but not recover the original private key if it's not on that system.

chrishiestand
  • 111
  • 2