Slashdot Mirror
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.
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!
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.
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.
Quo usque tandem abutere, Nimbus, patientia nostra?
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.
Wait, isn't this the same people making LibreSSL and a big fuzz about OpenSSL being insecure and leaving old and unused code around? Isn't this pretty much OpenSSH's Hearblead? Guess what we need know is a LibreSSH project.
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.
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?
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?
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?
My eyes reflect the stars and a smile lights up my face.
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.
Are there CVEs for these?
Karma: Bad
Yes. CVE-2016-0777 and CVE-2016-0778.
The many eyes are very slow....
A malicious server. I don't see how this can be exploited for anything useful. The client must have an account on the server and he must deliberately connect to it. So, it is an academic issue only.
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
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
Modern app appers know that only apps can app apps, so if it was changed to AppenSSH, it would use apps to app apps, not LUDDITE security keys!
Apps!
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.
Script to disable UseRoaming in Apple OS X https://gist.github.com/logica...
@LogicalMethods | www.sneaksneak.org
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 password-less SSH being possible to other devices these users control.
What the OpenSSH project needs to be doing now is explain in detail who put that code in there, how it came to be deployed and how it came to be on by default despite it clearly being an experimental feature. They need to identify at least one person or one contributing entity of either extreme stupidity or of malicious intent. And then they need to take steps to make sure this does not happen again.
OpenSSH has an excellent security track record, lets hope this is an isolated incident. Because if OpenSSH falls, most of the Internet infrastructure falls right after it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
This same thing was few years ago, one kiwi actually made a tool for exploiting it. Back the was rumours about US alphabet soups involvement.