Hacker News Reader

Comment by hamburglar | Hacker News Reader

> But if you use an agent, the client never loads the private key, so it's safe from memory disclosure vulnerabilities.

This is what I would assume, but has it been confirmed that this vulnerability doesn't affect identities provided by an SSH agent? If any of this "roaming" support was provided by the agent, it could be the case that the leakage can be triggered via SSH agent protocol requests. I doubt this is the case but I don't see anything confirming or denying it.

It would be nice to hear some official word on whether agent-based authentication is vulnerable, because if it isn't, the seriousness to me is greatly reduced, as I never load identities in the client directly.

View on HN

The Qualsys analysis states that keys provided by an agent are not disclosed, and that encrypted keys are disclosed in their encrypted form.

https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...

Quoting from above: Finally, for these three reasons, passphrase-encrypted SSH keys are leaked in their encrypted form, but an attacker may attempt to crack the passphrase offline. On the other hand, SSH keys that are available only through an authentication agent are never leaked, in any form.

So if you use an agent, and follow the good advice to encrypt your private keys you should be safe(er).

See for older client versions:

http://martin.kleppmann.com/2013/05/24/improving-security-of...

or better for newer clients:

http://www.tedunangst.com/flak/post/new-openssh-key-format-a...

The main issue identified by Qualys is a more generic memory disclosure bug:

https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...

This means they are basically able to dump the memory of just the running `ssh` process -- eerily similar to Heartbleed.

This means private keys stored by the `ssh-agent` process, outside of the `ssh` process connecting to an Evil Server(TM) are not affected.

This is because the protocol used between SSH Agent and SSH client does not transfer the entire private key, rather the SSH client asks the Agent to do a signing operation on it's behalf.

Good to know. Note regarding your final sentence, however: this design does not necessarily prevent the SSH agent from having a bug which can cause key disclosure via the agent protocol. It returns data buffers, so if it could be tricked into leaking key material into those data buffers, it may end up getting sent back to the server just the same (e.g. as a signature value). This would, however, be a bug in the agent and not the client.

Reply on news.ycombinator.com