OpenSSH Patches Bug That Leaks Private Crypto Keys (threatpost.com) 60
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.
Wow, apt is faster than slashdot (Score:5, Informative)
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 (Score:4, Informative)
apt is *NOT* faster than slashdot (Score:3)
Thu 14 Jan 2016 :: 16:59:07 EST (-0500)
# apt-get install openssh-client ...
Get:3 http://security.debian.org/ [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
Re: (Score:1)
Debian and other distributions frequently backport patches for older versions.
I'm using: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.4, OpenSSL 1.0.1f 6 Jan 2014
And it's patched for:
* SECURITY UPDATE: information leak and overflow in roaming support
- debian/patches/CVE-2016-077x.patch: completely disable roaming option
in readconf.c.
- CVE-2016-0777
- CVE-2016-0778
Re: (Score:2)
never mind, from the DSA, they back ported the changes
For the stable distribution (jessie), these problems have been fixed in
version 1:6.7p1-5+deb8u1.
In my defense it does not say that in the advisory upon install...
Re: Wow, apt is faster than slashdot (Score:2)
Um, yeah, we want the distros to get patches out before full-disclosure.
In this case, it's not just DiceDot being slow. We can come back tomorrow for the story about all the Nest thermostats failing today and bitch about it then.
Ditto! (Score:2)
The following packages will be upgraded:
openssh-client openssh-server openssh-sftp-server
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,060 kB of archives.
After this operation, 238 kB disk space will be freed.
I wonder if oldstable/Wheezy got them quickly too?
Undocumented features?! (Score:3, Insightful)
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?! (Score:3, Funny)
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?! (Score:1)
The other thing about this is the undocumented feature allowing resumption of wonky connections sounds a bit like Mosh. A feature I would actually like to see in openssh itself. Mosh is still not compatible with enough clients for me as yet.
After patching this (which does sound unlikely to be explored issue to be fair for most implementations). They should concentrate on finishing and documenting that feature.
Re: Undocumented features?! (Score:1)
explored/exploited..
Re: (Score:3)
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.
Re: (Score:2)
And they found this and patched it very fast.
And then completely screwed up responsible disclosure, because apparently time zones are hard.
Re: (Score:2)
...and when you scroll all the way to the bottom.. (Score:5, Informative)
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 (Score:4, Informative)
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 (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:1)
Yes. CVE-2016-0777 and CVE-2016-0778.
Affects me, the last two companies I worked for (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:4, Interesting)
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.
LibreSSL? (Score:1)
Re: (Score:1)
Re: (Score:2)
Not comparable.
Location of ssh_config on OS X (Score:2, Informative)
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?
Re: (Score:1)
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?
Should be:
Host *
(-> tab over) UseRoaming no
Put a tab before 'UseRoaming no' - http://www.undeadly.org/cgi?action=article&sid=20160114142733
Wait WHAT? (Score:3)
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: (Score:1)
It's a bug.
These things happen.
Sincerely,
The NSA.
Re: (Score:3)
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.
Correct me if I am wrong (Score:2)
But since this is a client bug, you would actually have to connect to a malicious SSHD session, correct?
If that is the case... I don't see how this is a huge deal. Who SSH's to weird unknown servers?
Re: (Score:1)
Or, for that matter, that your connection to the good server hasn't been re-routed to an evil one?
(The NSA likes to do that kind of thing)
Re: (Score:2)
The vulnerability is after host authentication, so that would trigger the usual host key mismatch red flags.
Re: (Score:3)
Re: (Score:1)
Script-kiddies working for China/Russian Government.
Shame this feature got patched. It sounds like it was a really great "cracker-jacker"! Suddenly every server compromised by the script-kiddies is a honeypot for the NSA. This is a great example of how a "good offense is a good defense". Or maybe: "how a suspiciously weak defense may be an offense in disguise?"
IDK: the point is, having damn near 100% transparency, on every SSH shell, on damn near every single bad guy tunnel is pretty fucking neat for the go
Re: (Score:3)
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 wi
Re: (Score:2)
But since this is a client bug, you would actually have to connect to a malicious SSHD session, correct?
If that is the case... I don't see how this is a huge deal. Who SSH's to weird unknown servers?
It is pretty common for git. Upload your public key and then connect using git over SSH. All it takes from then is to compromise the git-servers, or use a DNS attack to get the connection to the wrong servers.
Re: (Score:2)
And before that, it was common with CVS & SVN. Probably with Mercurial, Bazaar, and Arch as well.
Re: (Score:2)
In addition to all the version control software that supports "ssh:" protocols (from CVS up through git), there's those servers at work that lots of us connect to, without knowing who may have installed what on them.
Of course, if your work has rogue admins who are installing trojan ssh servers (or are simply so bad at their jobs that they allow outsiders to install trojan ssh servers), then you've definitely got bigger problems. But fixing the leak on your side and updating your keys will at least cover you
SSH Agent (Score:2)
Apparently, if you use ssh-agent then the keys in the agent cannot be leaked with this exploit.
Whew... I always use ssh-agent. But I've added UseRoaming no to all my boxes just to be safe anyway.
Re: (Score:2)
for something that doesn't and can't apply in 99.99% of use cases....not losing any sleep over this vulnerability
Here is a script to disable UseRoaming in OSX (Score:2)
Strikes me as an intentional vulnerability (Score:1)
I.e. as an intentional attack against the OpenSSH project. First, nobody in any halfway professionally run project deploys experimental code to to production, especially when said code does nothing because the server-side implementation is missing. Activating it per default is also extremely suspicious. And second, the last backdoors found in firewalls are in devices that you typically would use SSH to log in to, i.e. these devices could attack their users, extract the users private keys and then check for