Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Encryption Bug Open Source

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.
This discussion has been archived. No new comments can be posted.

OpenSSH Patches Bug That Leaks Private Crypto Keys

Comments Filter:
  • by NotInHere ( 3654617 ) on Thursday January 14, 2016 @04:19PM (#51302637)

    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!

    • 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

      • by Anonymous Coward

        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

      • by Froze ( 398171 )

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

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

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

  • by spectrum- ( 158197 ) <gsmitheidw@g m a i l.com> on Thursday January 14, 2016 @04:20PM (#51302639) Homepage

    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.

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

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

    • by gweihir ( 88907 )

      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 they found this and patched it very fast.

        And then completely screwed up responsible disclosure, because apparently time zones are hard.

  • by Penguinisto ( 415985 ) on Thursday January 14, 2016 @04:20PM (#51302641) Journal

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

    • by NotInHere ( 3654617 ) on Thursday January 14, 2016 @04:23PM (#51302655)

      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.

    • by kthreadd ( 1558445 ) on Thursday January 14, 2016 @04:25PM (#51302671)

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

  • by Anonymous Coward
    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.
  • by 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?

    • by 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?

      Should be:
      Host *
      (-> tab over) UseRoaming no

      Put a tab before 'UseRoaming no' - http://www.undeadly.org/cgi?action=article&sid=20160114142733

  • by cfalcon ( 779563 ) on Thursday January 14, 2016 @04:33PM (#51302727)

    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?

    • by Anonymous Coward

      It's a bug.

      These things happen.

      Sincerely,
      The NSA.

    • by gweihir ( 88907 )

      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.

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

    • by Anonymous Coward

      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

    • 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

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

      • by Xtifr ( 1323 )

        And before that, it was common with CVS & SVN. Probably with Mercurial, Bazaar, and Arch as well.

    • by Xtifr ( 1323 )

      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

  • Apparently, if you use ssh-agent then the keys in the agent cannot be leaked with this exploit.

    Finally, for these three reasons, passphrase-encrypted SSH keys are leaked in their encrypted form, but an attacker may attempt to crack the passphrase offline. On the other hand, SSH keys that are available only through an authentication agent are never leaked, in any form.

    Whew... I always use ssh-agent. But I've added UseRoaming no to all my boxes just to be safe anyway.

  • Script to disable UseRoaming in Apple OS X https://gist.github.com/logica... [github.com]
  • 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

You're at Witt's End.

Working...