3 ms·
> If you were to mandate a key rotation across all employees and mandate all employees use a keypair prepared for work and no other purpose I would rate those m
by agwa 11y ago
> If you were to mandate a key rotation across all employees and mandate all employees use a keypair prepared for work and no other purpose I would rate those mandates as not being excessive.
A better mandate would be to use ssh-agent. Using separate key pairs without an agent doesn't prevent key theft due to memory disclosure vulnerabilities like this one; it merely compartmentalizes the damage. But if you use an agent, the client never loads the private key, so it's safe from memory disclosure vulnerabilities. Stealing a private key would require filesystem access or remote code execution, at which point all of your private keys are at risk, so you might as well just use a single private key per device.
For the best security, store your private key on a smartcard, so even an attacker with filesystem access or remote code execution can't steal it.
- hamburglar 11y ago> 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.
- pquerna 11y agoThe main issue identified by Qualys is a more generic memory disclosure bug: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt 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.
- hamburglar 11y agoGood 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.
- ams6110 11y agoThe 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-0778/openssh-cve-2016-0777-cve-2016-0778.txt 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-ssh-private-keys.html 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-and-bcrypt-pbkdf http://www.tedunangst.com/flak/post/new-openssh-key-format-a...