PSA: Critical bug in OpenSSH

[colonel_mortis]

Sources: Digital Ocean, OpenBSD Journal
CVE IDs: CVE-2016-0777 and CVE-2016-0778
 
A critical bug has been identified in the OpenSSH client software which could allow a client's private key to be leaked (which would allow an attacker to perform MitM attacks on your SSH connection or to log in as you). The bug exists in some experimental code, which doesn't actually do anything yet because it has only been enabled in the client version, and not in the server.

A key exchange is initiated when an SSH client connects to a server. A new "roaming" feature included in the OpenSSH client can be exploited and a malicious server could use this issue to leak client memory to the server, including private client user keys.

 
This vulnerability doesn't affect PuTTY on Windows, but if you have installed OpenSSH on Windows then you are vulnerable; OpenSSH is also preinstalled on almost all Linux and Unix OSes, including OSX.
Only the client version (that you run on the computer that you are using) is vulnerable - the server version doesn't have the vulnerable code enabled.
 
How to mitigate the vulnerability:
This issue has been patched in OpenSSH 7.1p2, which released on Friday 15th Jan and is being rolled out through the standard channels, so update your OpenSSH using apt, yum, etc, or by building it from source.
If the fixed version isn't available for you yet, you can disable the vulnerable feature by adding UseRoaming no to your ssh_config file. If you're running Linux, you can do this by running

echo 'UseRoaming no' | sudo tee -a /etc/ssh/ssh_config

On OSX, you can use

echo "UseRoaming no" >> ~/.ssh/config

This will have no adverse affect on OpenSSH because, while the feature was enabled by default in the client code, it isn't supported by the server versions of OpenSSH, so it is never actually used.

 

If you have connected to a malicious server, or a server that you suspect may possibly have ever been malicious, you should also assume that your SSH key has been compromised, and generate new ones. To the best of my knowledge, there is no risk of your private key having been exposed if you have only ever connected to servers that you know are safe.

[Trik'Stari]

Well that's not good.

 

What is this new roaming feature supposed to be used for?

[colonel_mortis]

Well that's not good.

 

What is this new roaming feature supposed to be used for?

As far as I can see, it appears to be to allow you to resume an existing SSH connection, though I'm not sure quite how that would work.

[Centurius]

This is why you should always put things like ssh behind a private network.

[LAwLz]

This is why you should always put things like ssh behind a private network.

What do you mean by "put it behind a private network"? SSH is at its best when you are on an open network.

[LeapFrogMasterRace]

This is why I never make accounts through the forum.

[colonel_mortis]

This is why I never make accounts through the forum.

I'm not sure what you mean... This isn't a vulnerability with the forum, it's a vulnerability in a piece of software that is used to remotely manage servers.

[Centurius]

What do you mean by "put it behind a private network"? SSH is at its best when you are on an open network.

On a private range only accessible by either a secured VPN or one of the other secured systems but never on the public internet directly.

[Misanthrope]

I use something called putty for ssh at work, not sure if it's based on openssh

[colonel_mortis]

I use something called putty for ssh at work, not sure if it's based on openssh

PuTTY is not affected by this (it does say so in the OP).

[Misanthrope]

PuTTY is not affected by this (it does say so in the OP).

 

Missed that, my bad. 

[StackUnderflow]

Awesome, an excuse to not do any work for the next week. (/s)

[LAwLz]

On a private range only accessible by either a secured VPN or one of the other secured systems but never on the public internet directly.

Then you are missing the point of SSH. If you got a direct VPN tunnel then there isn't really any point in using SSH instead of Telnet since it will be encrypted anyway (although you should still use SSH).

The good thing about SSH is that you can use it over public channels without worrying.

[Centurius]

Then you are missing the point of SSH. If you got a direct VPN tunnel then there isn't really any point in using SSH instead of Telnet since it will be encrypted anyway (although you should still use SSH).

The good thing about SSH is that you can use it over public channels without worrying.

SSH still has other advantages over telnet. In theory you can use SSH over a public channel without worrying but as this shows that's far from certain and it isn't the first major vulnerability to be discovered in SSH implementation. While a VPN won't be 100% guaranteed security either pretty much everyone I know in the field uses it because having only a single mechanism in between the public internet and root access to a system is too big a risk.

[lkarej]

I don't even know what SSH is.

But that's not good.

[Nowak]

I don't even know what SSH is.

But that's not good.

Secure Shell. Basically a secure (or meant to be secure) way of remotely administrating Unix and Unix-like operating systems over a command line interface. Basically like a terminal on the machine, but you're using it on a different machine.

[lkarej]

Secure Shell. Basically a secure (or meant to be secure) way of remotely administrating Unix and Unix-like operating systems over a command line interface. Basically like a terminal on the machine, but you're using it on a different machine.

ah ok

thanks for the explanation

[Misanthrope]

SSH still has other advantages over telnet. In theory you can use SSH over a public channel without worrying but as this shows that's far from certain and it isn't the first major vulnerability to be discovered in SSH implementation. While a VPN won't be 100% guaranteed security either pretty much everyone I know in the field uses it because having only a single mechanism in between the public internet and root access to a system is too big a risk.

 

Aye: work insists on both VPN and SSH to access their DB remotely. In fact I don't know if they even have a public facing address since I haven't been able to resolve it while not on domain. It is entirely possible that they just didn't set that up because they didn't know how however: the IT department running that Oracle Linux install is pretty amateurish. 

[Centurius]

Aye: work insists on both VPN and SSH to access their DB remotely. In fact I don't know if they even have a public facing address since I haven't been able to resolve it while not on domain. It is entirely possible that they just didn't set that up because they didn't know how however: the IT department running that Oracle Linux install is pretty amateurish. 

Yeah, they probably don't. I know most of my own servers are set up to only listen on the private range while those that need to face to the public(actual webserver and such) have a firewall restricting ssh to the private range.

[LAwLz]

SSH still has other advantages over telnet. In theory you can use SSH over a public channel without worrying but as this shows that's far from certain and it isn't the first major vulnerability to be discovered in SSH implementation. While a VPN won't be 100% guaranteed security either pretty much everyone I know in the field uses it because having only a single mechanism in between the public internet and root access to a system is too big a risk.

The "other advantages" is authentication, but that's it.

There is no "in theory" about it. It is done in practice as well. You don't always have a VPN running end to end because that would be stupid. Secure, but impractical and wasteful.

VPNs are great, but VPN and SSH are used for different purposes and for a wide variety of reasons you can't or shouldn't use both at the same time,100% of the time.

Besides, this exploit is for infected servers. A VPN would not protect you from this since it would be the server stealing the client's private key.

Yeah, they probably don't. I know most of my own servers are set up to only listen on the private range while those that need to face to the public(actual webserver and such) have a firewall restricting ssh to the private range.

Oh now I understand why you said the things you said. You work with servers while I mostly work with routers. Sure, configure a server to only listen to private addresses if you want. Configuring a router to only listen to internal addresses is not always such a good idea though.

[colonel_mortis]

The "other advantages" is authentication, but that's it.

There is no "in theory" about it. It is done in practice as well. You don't always have a VPN running end to end because that would be stupid. Secure, but impractical and wasteful.

VPNs are great, but VPN and SSH are used for different purposes and for a wide variety of reasons you can't or shouldn't use both at the same time,100% of the time.

Besides, this exploit is for infected servers. A VPN would not protect you from this since it would be the server stealing the client's private key.

Oh now I understand why you said the things you said. You work with servers while I mostly work with routers. Sure, configure a server to only listen to private addresses if you want. Configuring a router to only listen to internal addresses is not always such a good idea though.

In fact, you can use OpenSSH to create a proxy (I'm not 100% sure if it's a VPN or not - it might not be encrypted) using SSH for authentication (and potentially for encrypting the traffic too).

[Bittenfleax]

Awesome, an excuse to not do any work for the next week. (/s)

Haha, nice name, it makes me laugh because I hate that place.

 

But you could just use Putty instead? Or turn off Roaming on OpenSSH.

[Blade of Grass]

In fact, you can use OpenSSH to create a proxy (I'm not 100% sure if it's a VPN or not - it might not be encrypted) using SSH for authentication (and potentially for encrypting the traffic too).

I believe that a SOCKS proxy created through OpenSSH is secure (at least, between you and your server) as it runs through the SSH tunnel.