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.

Re:Undocumented features?!

[gweihir]

This must be a combination of somebody really messing up (allowing experimental and enabled code into a production release) and somebody asking for it, either because of stupidity or because of malicious intent.

No reason to dump OpenSSH, the project has an excellent security track record. And they found this and patched it very fast. But they have some explaining to do and they need to make sure something like this does not happen again.

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

Wait WHAT?

[cfalcon]

Why is the DEFAULT option to USE a feature that doesn't even work? Not only is the experimental code in the baseline for some reason, not only is it nonfunctional (and therefore not testable), but it's ENABLED BY DEFAULT?

Bug, or someone's feature?

Re:Wait WHAT?

[gweihir]

Only two options: 1. extreme stupidity coupled with completely unprofessional behavior or 2. malicious intent. This is just far too nice and works too well with the recently discovered backdoors in Firewalls (which are devices you would use SSH to log into) to be an accident IMO. Finger-pointing with evidence is pretty much a must at this point.

Re:Correct me if I am wrong

[kthreadd]

Not necessarily. If the attacker only has access to that one server then that's just one server. If the attacker was able to get my private ssh key then the attacker now has access to all servers. Neither situations are great but that's a pretty big difference.

Re:Correct me if I am wrong

[SlashdotOgre]

That's my understanding as well, and I generally agree with your sentiment for home use however it is still a pretty significant bug. For most folks that always connect to the same systems that you trust, it's not a big issue. However if you're in a position where you're constantly connecting to new servers (i.e. at a large company), the fact that your private key can be leaked is very scary. Normally the biggest risk of connecting to an unknown server is getting your password stolen (i.e. A bad actor with dtrace access can debug sshd), but they would normally still not get your private key. With this but, a bad actor can easily get both.

apt is *NOT* faster than slashdot

[Froze]

Thu 14 Jan 2016 :: 16:59:07 EST (-0500)

# apt-get install openssh-client ...
Get:3 http://security.debian.org/ jessie/updates/main openssh-client amd64 1:6.7p1-5+deb8u1 [691 kB]

this is not 7.1p2 needed to mitigate this bug.

Reposted non-anon to bump bonus

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

Here is a script to disable UseRoaming in OSX

[lanimreT]

Script to disable UseRoaming in Apple OS X https://gist.github.com/logica...

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.