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.

...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.

Location of ssh_config on OS X

[Anonymous Coward]

This file is in /etc/ssh/ssh_config

The line to add is: UseRoaming no

What is the recommended upgrade path here, waiting for an OS X patch, or manually installing and upgrading via brew tap homebrew/dupes and brew install openssh?

I'm confused about what vest practice is for keeping homebrew installed packages that are security critical up to date. It seems cumbersome to do a brew update and brew info every so often. What is the automated solution here?

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).