OpenSSH Patches Bug That Leaks Private Crypto Keys (threatpost.com)

msm1267 writes: OpenSSH today released a patch for a critical vulnerability that could be exploited by an attacker to force a client to leak private cryptographic keys. The attacker would have to control a malicious server in order to force the client to give up the key, OpenSSH and researchers at Qualys said in separate advisories. Qualys' security team privately disclosed the vulnerability Jan. 11 and the OpenSSH team had it patched within three days. The vulnerability was found in a non-documented feature called roaming that supports the resumption of interrupted SSH connections. OpenSSH said client code between versions 5.4 and 7.1 are vulnerable as it contains the roaming support. OpenSSH said that organizations may disable the vulnerable code by adding 'UseRoaming no' to the global ssh_config(5) file. Researchers at Qualys said organizations should patch immediately and regenerate private keys.

Comments

Wow, apt is faster than slashdot

[NotInHere]

I knew that there has been updates for openssl since I last ran apt-get update && apt-get dist-upgrade, it asked me to update the "openssh-client" package.

good job, debian guys!

Re:Wow, apt is faster than slashdot

[kthreadd]

Debian and many other GNU/Linux distros tend to backport patches rather than updating to the new upstream release directly. That's because upstream releases often include other changes that might disrupt the way users use the software. Debian may also include a number of local patches in their version and these might break when rebasing onto a new version. So when they backport a patch they typically don't update the version number except for the last part, in this case the -6 at the end which is a Debian add-on. So it's the sixth Debian patch to the 7.1p1 upstream release that you have there, not 7.1p1 as released by upstream.

Undocumented features?!

[spectrum-]

Undocumented features in security focused software. This doesn't sound like a good idea! Test or unfinished features should probably go in code forks or unreleased prototypes far from production use.

Re: Undocumented features?!

[Anonymous Coward]

This is actually somewhat embarrassing for the OpenSSH project. Maybe the LibreSSL folks can step up and make aLibreSSH version of OpenSSH. They seem to know their stuff with security.

...and when you scroll all the way to the bottom..

[Penguinisto]

“Its exploitation requires two non-default options: a ProxyCommand, and either ForwardAgent (-A) or ForwardX11 (-X),” Qualys said. “This buffer overflow is therefore unlikely to have any real-world impact.”

99.9% of all *nix servers on the planet with SSH on them do not use either option. Good that they patched it, but otherwise, I don't think I'm going to be in a massive hurry to do a crash-patching this weekend.

Re:...and when you scroll all the way to the botto

[NotInHere]

If you actually scroll a bit up, you'll see that there were two bugs: one information leak, that exposes the private crypto keys, and a buffer overflow, not exploitable if the non-default options are set.

Re:...and when you scroll all the way to the botto

[kthreadd]

“Its exploitation requires two non-default options: a ProxyCommand, and either ForwardAgent (-A) or ForwardX11 (-X),” Qualys said. “This buffer overflow is therefore unlikely to have any real-world impact.”

99.9% of all *nix servers on the planet with SSH on them do not use either option. Good that they patched it, but otherwise, I don't think I'm going to be in a massive hurry to do a crash-patching this weekend.

It's a client-side bug, and both agent and X11 forwarding are fairly common there.

Affects me, the last two companies I worked for

[raymorris]

This issue affects anyone who connects to customer machines via SSH. If ANY customer machine is infected, the attacker can read my private key, which allows them to connect to and potentially infect ALL of my customers.

Consider a hosting provider such as Rackspace or Hostgator. The Hostgator sysadmin spends his day connecting to various servers used by Hostgator customers. As soon as he logs into one server which is infected, the bad guys have his keys and can use them to infect ALL Hostgator servers, tens of thousands of servers.

Re:Affects me, the last two companies I worked for

[marcansoft]

Only if you don't use an SSH agent. If you use an agent to store your keys, they are safe. Even if your keys leak because you're not using an agent, they can only leak in encrypted form (you use passphrases, don't you?). When the vulnerability is about to be triggered, a strange message (connection suspended, press return to resume) appears and must be dismissed (if you ^C at that point, you are safe).

In otherwords, this is a panic situation only for people using non-passphrased keys and no SSH agent. You also have to accept a prompt that is not normal and should raise red flags before the vulnerability can happen. People who fit that description probably have other security problems to worry about.

More realistically, you should patch your servers if you use any kind of SSH-based automation (e.g. where one master server uses SSH to automate tasks on slaves), since this allows an attacker to escalate from a target machine to the automation machine. But that requires first compromising the target, so it is not an emergency situation (unless your machines are already compromised and you don't know it, in which case, again, you have bigger problems).

true, automated tasks the main risk

[raymorris]

That's true, the main risk is automated scripts, which don't use an agent and won't notice the odd prompt. Again though that includes large installations like Rackspace, Hostgator, etc. Anybody who has thousands of servers doesn't log into each one individually all the time, they script updates, backups, configuration, etc. And several bulk protocols including rsync, git, etc run on top of ssh.

I'm certainly got my attention because a system I'm responsible for has one heavily fortified gateway machine which has access to many customer servers. I'm glad the bad guys didn't know about this before the good guys did, as far as we know.