This morning, a new and mildly concerning (I am British, therefore I genetically predisposed to the gift of the understatement: http://thoughtmeme.blogspot.co.uk/2013/02/a-masterpiece-of-understatement.html) bug has been discovered in OpenSSH clients.
The feature, SSH roaming, was never fully implemented and yet seemingly the code is still present and on by default on Open SSH clients, despite not being in the server versions. It was supposed to allow for the resumption of dropped SSH sessions by allowing the client and server to re-exchange keys in the background.
The bugs themselves do not allow for an evil server or man-in-the-middle to directly request keys from a client, but they do enable a buffer overflow to be sent to the client which could allow for information resident in memory to be leaked, most worryingly this includes your SSH keys.
So, what can you do about it?
The feature, SSH roaming, was never fully implemented and yet seemingly the code is still present and on by default on Open SSH clients, despite not being in the server versions. It was supposed to allow for the resumption of dropped SSH sessions by allowing the client and server to re-exchange keys in the background.
The bugs themselves do not allow for an evil server or man-in-the-middle to directly request keys from a client, but they do enable a buffer overflow to be sent to the client which could allow for information resident in memory to be leaked, most worryingly this includes your SSH keys.
So, what can you do about it?
- Switch the vulnerable code off by adding "UseRoaming no" to your client SSH configuration.
- If "[connection suspended, press return to resume]" appears in stderr during a session, break the session, as this is client responding to an attempted resumption of a session by server which "supports" roaming. As roaming was never actually implemented on OpenSSH server, you can be assured this isn't a good thing...
- Protect your keys with a passphase, but we all do this anyway, right?
- Don't use keys. I shall await your fire on this one. I've always maintained that a good, well enforced, audit-able password policy > poorly implemented key management. You root into your servers using a key which is two years old and shared by all sysadmins? Then you have bigger worries than this bug.
- Use two-factor auth.
- Restrict inbound SSH connections by IP address, either at the network or application level.
My thanks to the excellent write up from Qualys here: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt
Comments
Post a Comment