Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSH: client bug CVE-2016-0777

undeadly.org

Post reply on HN
Print view View original

141–150 of 226 posts

Re: OpenSSH: client bug CVE-2016-0777

#141

Post by pmuk »

clort wrote: post #101
joe_bleau wrote: post #100

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.

does this require a ssh server running on localhost?

Yes, that command is connecting to an ssh server on localhost, but you could connect to any ssh server that you trust...

  ssh -v -T git@github.com 2>&1 | grep -i 'roaming'

Re: OpenSSH: client bug CVE-2016-0777

#142

Post by jldugger »

ralphm wrote: post #59
gnur wrote: post #57

Earlier quoted context omitted.

It's from the linked page.

Indeed. The page gives bad advise. If your config has `Host` blocks, like often in people's personal configs, or if you have a `Match` block, the new directive only applies to the last of those blocks in the config file.

Which is why they're appending a newline and Host *?

Re: OpenSSH: client bug CVE-2016-0777

#143

Post by skykooler »

mapgrep wrote: post #103
majewsky wrote: post #70

Earlier quoted context omitted.

Hue? There is one on mine. Maybe mine's different because I upgraded from 10.9 to 10.10 to 10.11 whereas you might have started with a later version (or an earlier one)?

You have an /etc/ssh, or just an /etc? I have /etc, which is a symlink to /private/etc, but as I said it has no ssh dir. FWIW I am on 10.10.5 not 10.11. Maybe there's a change in 10.11. (The article the grandparent links is focused on 10.10 so I assumed that was in the scope of this discussion.) PS are you on homebrew? maybe homebrew adds it.

Homebrew should not add anything outside of /usr/local iirc.

Re: OpenSSH: client bug CVE-2016-0777

#144

Post by Xylakant »

aexaey wrote: post #120
mioelnir wrote: post #107

Earlier quoted context omitted.

You also need to set IdentitiesOnly yes if I remember the config setting correct. Note however that this only limits the offered keys during the authentication phase. If you use AgentForwarding, this still has the entire keyring available afterwards.

Don't use SSH agent forwarding. https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-con...

which is not very helpful if you for example want to run git via ssh or similar commands on the target server.

There's places where there are two alternatives: agent forwarding or copy the key. Using ssh agent forwarding allows me to use a smart card for the key. It still has it's problems but it's much better than having the key on the remote machine - for example the use of a smartcard mitigates this vulnerability since the key never enters the process memory.

Re: OpenSSH: client bug CVE-2016-0777

#145

Post by jldugger »

tomjen3 wrote: post #140
aexaey wrote: post #134

Does anybody else find this eerily reminiscent of heartbleed? Obscure broken feature that nobody uses (or needs) is enabled by default and allow private keys to leak.

It is OpenSSH, the clown car of bugs in obscure features nobody uses. Does anybody know if LibraSSL has released an SSH client yet? I can't code well enough to make security code safe, so I won't be able to help them out on it, but it sounds more and more like OpenSSH can't either.

You seem confused. The LibreSSL people released a SSH client years ago, called OpenSSH. Which is not the same as OpenSSL, which suffered Heartbleed.

Re: OpenSSH: client bug CVE-2016-0777

#146

Post by Xylakant »

feld wrote: post #118
devin wrote: post #116

Am I correct that YubiKey users are unaffected by this vulnerability? As I understand it, the private key never enters into memory.

I guess it depends on what you mean? I have yubikey 2FA on my servers for SSH, but also have SSH keys. I use SSH keys when I can, and yubikey when I don't have my SSH keys handy. I suppose if you're doing yubikey+password auth and don't have any keys configured for your ssh client you're fine because... you don't have any keys? :)

yubikeys support ssh key auth (via gpg-agent in ssh mode). It's sometimes a bit wobbly, but in general works fine.

Re: OpenSSH: client bug CVE-2016-0777

#148

Post by singlow »

hamburglar wrote: post #97

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?

I would love to hear from someone who knows the answer to this. Does this affect ssh-agent? I am rotating my keys regardless, but I am curious.

Re: OpenSSH: client bug CVE-2016-0777

#149

Post by rchiniquy »

patio11 wrote: post #83

Use the workaround immediately and patch ASAP, both on your workstation and across your infrastructure where SSH is used, which can be in surprising places. SSH is designed so that, even if you connect to an evil host, the host only learns your public key, not your private key. This leaks your private key to an evil host. You might think "I only SSH into boxes that I own, so I'm good, right?", but if you in the futur…

If you were to mandate a key rotation across all employees and mandate all employees use a keypair prepared for work and no other purpose I would rate those mandates as not being excessive.

As patio11 notes, this would not at all be excessive as a response to the threat model, but even with an aggressive key rotation mandate, this still doesn't make your production infrastructure as secure as your corporate Confluence wiki with SSO. Your employee's private key is still a static credential, and any rotation policy (14 days? 30 days? 90 days?) will leave a significant window for an attacker to use a stolen credential. Additionally, using a single key per employee for all infrastructure access magnifies the attack surface of a stolen credential to everything you operate.

Full disclosure, I'm a co-founder at ScaleFT, a startup focused on solving these sorts of problems. We're releasing a patch to fully mitigate this for our users this morning.

Re: OpenSSH: client bug CVE-2016-0777

#150

Post by nulltype »

If you have a mac (Yosemite), it looks like you want to add " UseRoaming no" under the "Host *" line in /etc/ssh_config (as root). You can test it before and after with this:

ssh -v -T git@github.com 2>&1 | grep Roaming

debug1: Roaming not allowed by server ssh -v -T git@github.com 2>&1 | grep Roaming

(no output is good)

Post reply on HN