OpenSSH: client bug CVE-2016-0777 • Hacker News Board

Re: OpenSSH: client bug CVE-2016-0777

#91

Post by axelfontaine » Thu, Jan 14, 2016, 4:44 PM UTC

We went to other way and kissed SSH goodbye a long time ago in favor of immutable infrastructure and automation: https://boxfuse.com/blog/no-ssh

Re: OpenSSH: client bug CVE-2016-0777

#92

Post by fixermark » Thu, Jan 14, 2016, 4:45 PM UTC

So how does the exploit actually work? How can a malicious sshd actually use this to acquire the private key?

Re: OpenSSH: client bug CVE-2016-0777

#93

Post by narsil » Thu, Jan 14, 2016, 4:57 PM UTC

jlgaddis wrote: post #2

Workaround (yes, it's client-side): # echo -e "Host *\n\tUseRoaming no\n" >> /etc/ssh/ssh_config Disclaimer: won't work on all operating systems, shells, etc. YMMV. Consult a doctor before following any advice you get from the Internet. Void where prohibited. Restrictions may apply. Edited per comments below

I'm emailing the one-liner to folks and found it helpful to just include the root subshell:

    sudo bash -c 'echo -e "Host *\n\tUseRoaming no\n" >> /etc/ssh/ssh_config'

Re: OpenSSH: client bug CVE-2016-0777

#94

Post by _yy » Thu, Jan 14, 2016, 5:01 PM UTC

drzaiusapelord wrote: post #67

StefanKarpinski wrote: post #34

Does it strike anyone else as bizarre / poor form for an experimental feature to be enabled by default in OpenSSH, which is normally very conservative with option defaults?

It just sounds like a big code-base fuckup. They more or less admit it: "Server side was disabled/gutted for years already, but this aspect was surprisingly forgotten." Sounds like this was put in at one time, forgotten about, and the code lingered for a long time until someone pointed it out. SSH as a protocol is pretty crazy. Everyone loves it, but its a lot of things in one, which ironically goes against the unix…

SCP/SFTP is actually a separate binary.

PuTTY is definitely not affected since it has its own SSH implementation.

Re: OpenSSH: client bug CVE-2016-0777

#95

Post by rsync » Thu, Jan 14, 2016, 5:05 PM UTC

merqurio wrote: post #5

As far as I know, this will affect any OSX, am I right ?

It will affect any OSX that is new enough to have that code in it. Same is true with other OS. For instance, on an older, patched FreeBSD 7.2 system, we see this result:

  /root/.ssh/config: line 1: Bad configuration option: UseRoaming
  /root/.ssh/config: terminating, 1 bad configuration option

... which means that sshd predates the roaming code. I haven't tested, but I'll bet my snow leopard workstation also predates that code.

So ... if that line:

  UseRoaming no

produces no errors when you ssh as that user, then you had the problem and you fixed it. If it produces the error above, you never had the problem in the first place (although with an older sshd like that, you should make sure you're not exposed to other, older vulnerabilities).

Re: OpenSSH: client bug CVE-2016-0777

#96

Post by jlgaddis » Thu, Jan 14, 2016, 5:06 PM UTC

snowwrestler wrote: post #87

jlgaddis wrote: post #76

Earlier quoted context omitted.

I updated /private/etc/ssh_config on OS X (system-wide vs. user-specific).

I believe that is the config for the daemon, not the client. I think you want ssh_config.

Yeah, typo'd it in my comment above. Thanks, fixed.

Re: OpenSSH: client bug CVE-2016-0777

#97

Post by hamburglar » Thu, Jan 14, 2016, 5:07 PM UTC

How does a client bug end up leaking private key material to the server if the private key is in an entirely different process (the agent)? Or is this only an issue if you are loading your identity directly in the client?

Re: OpenSSH: client bug CVE-2016-0777

#98

Post by scardine » Thu, Jan 14, 2016, 5:07 PM UTC

protomyth wrote: post #78

Check me on this, so this is a client-side problem only, so ssh-ing into only know servers shouldn't be an issue and clients cannot cause problems for servers?

If an enemy takes control of just one of the hosts you ssh into, he will get your private key and can use it to ssh into any other box where you use RSAAuthentication.

Re: OpenSSH: client bug CVE-2016-0777

#99

Post by icebraining » Thu, Jan 14, 2016, 5:08 PM UTC

drzaiusapelord wrote: post #67

StefanKarpinski wrote: post #34

Does it strike anyone else as bizarre / poor form for an experimental feature to be enabled by default in OpenSSH, which is normally very conservative with option defaults?

It just sounds like a big code-base fuckup. They more or less admit it: "Server side was disabled/gutted for years already, but this aspect was surprisingly forgotten." Sounds like this was put in at one time, forgotten about, and the code lingered for a long time until someone pointed it out. SSH as a protocol is pretty crazy. Everyone loves it, but its a lot of things in one, which ironically goes against the unix…

Related: "Protecting sshd using spiped" by cperciva

http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...

Re: OpenSSH: client bug CVE-2016-0777

#100

Post by joe_bleau » Thu, Jan 14, 2016, 5:10 PM UTC

Testing the ssh client config workaround:

   ssh -v user@localhost 2>&1 >/dev/null | grep -i 'roaming'

returns "debug1: Roaming not allowed by server" when vulnerable, and nothing when not. YMMV, only tested on a few machines, etc.