Live data from Hacker News

OpenSSH: client bug CVE-2016-0777

undeadly.org

191–200 of 226 posts

Re: OpenSSH: client bug CVE-2016-0777

#191
post #89

Earlier quoted context omitted.

This may be a start: Host * IdentityFile ~/.ssh/%h Comment: One key per host, named after the host you connect to

What if my infrastructure is over 50 hosts? How am I going to distribute key files for 50 people with 50 keys every 14 days?

You could use something like ansible for the management of keys. Or you could centralize your authentication, which would probably be a lot more sane.

Re: OpenSSH: client bug CVE-2016-0777

#192
post #89

Earlier quoted context omitted.

This may be a start: Host * IdentityFile ~/.ssh/%h Comment: One key per host, named after the host you connect to

What if my infrastructure is over 50 hosts? How am I going to distribute key files for 50 people with 50 keys every 14 days?

You automate it. At 50 hosts some automation like puppet or ansible, etc is worth the trouble, especially if it helps you make sure that all hosts have the correct keys on them - that's just basic security - make sure there are no keys that shouldn't be there.

What do you do now if someone leaves? Remove that person's key from all 50 hosts one at a time?

Or, at the very least, you use tmux with sync panes or csshx - and log into all 50 hosts at once, and then you can issue one rm / scp command if you are still doing things manually.

Re: OpenSSH: client bug CVE-2016-0777

#193

Earlier quoted context omitted.

What if my infrastructure is over 50 hosts? How am I going to distribute key files for 50 people with 50 keys every 14 days?

You could use something like ansible for the management of keys. Or you could centralize your authentication, which would probably be a lot more sane.

Even with central management, I don't know that I want to have 2500 keys floating around even if I have a management stack in place. That seems like an attack vector all in its own. Changing a key every other day on a 90 day rotation with 50 boxes. And fifty boxes isn't even that much. That's like 2 racks.

Even with config management this won't scale past about 2 or 3 people and 10-20 boxes.

Central auth is an option I guess but I think the better way to go would be a 2 factor with the key and hotp.

Re: OpenSSH: client bug CVE-2016-0777

#194

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)

A few of my friends found multiple copies of ssh_config lying around, so I wrote this one-liner that looks at 3 separate known ssh_config files & patches any vulnerable ones that it finds.

$ for SSH_CONF in /etc/ssh/ssh_config /etc/ssh_config /private/etc/ssh_config; do [ -f $SSH_CONF ] && ! grep -q 'UseRoaming no' $SSH_CONF && echo "Patching $SSH_CONF" && echo -e '\nHost *\n UseRoaming no' | sudo tee -a $SSH_CONF > /dev/null; done

Re: OpenSSH: client bug CVE-2016-0777

#195
post #30

Earlier quoted context omitted.

So the real question is, can a MITM intercept connections to boxen you frequent to exploit this? Or is it limited to connecting to hostile honeypots?

What is "boxen"?

Plural of UNIX (or equivalent) system [1]

[1] http://www.catb.org/jargon/html/B/boxen.html

Re: OpenSSH: client bug CVE-2016-0777

#196

Earlier quoted context omitted.

Ughhh, that's insane.

> Ughhh, that's insane. Not really. This is for deploy systems which deploy to a trusted environment (for instance through VPN, network security etc.).

Even if you are using some kind of prebaked images to deploy, you should be generating individual keys using the SSH PKI features per machine as part of your individual host configurations.

This allows you to verify hosts while having never seen their keys. Just totally shutting off verification is a horrible idea.

Re: OpenSSH: client bug CVE-2016-0777

#197

Earlier quoted context omitted.

OpenSSH server doesn't support roaming. This is a client only issue. The problem is that your connection could be MITM'd by someone looking to exploit this bug.

> your connection could be MITM'd MITM isn't a risk, if I understand this statement in the undeadly.org announcement: The authentication of the server host key prevents exploitation by a man-in-the-middle, so this information leak is restricted to connections to malicious or compromised servers.

Unless it's your first connection to a legit uncompromised server, yes? (AWS instance, etc)

Re: OpenSSH: client bug CVE-2016-0777

#198
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…

Ironically, ssh'ing into a random server is the exact thing you shouldn't do if you aren't patched.

Make sure you patch BEFORE doing something like ssh'ing into whoami.filippo.io "just because someone on the internet told me to"

This site is (from what I can tell) not malicicous, but copy pasting scripts and blindly following advice from the internet is a prime example of how an exploit would occur.

Re: OpenSSH: client bug CVE-2016-0777

#199
post #59

Earlier quoted context omitted.

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.

Sufficient to place it at the top of ~/.ssh/config? Or does it also need a block header of its own, like: Host * UseRoaming no

I confirmed that it does not need to be placed into a Host block, as long as it is above all of your blocks.

For instance:

   UseRoaming no

   Host *
      Blah yes
Test with: ssh -v remote.ssh.host.com uptime 2>&1 | grep -i roaming

If it returns nothing, the config fix is active. If it isn't active, you'll see 'debug1: Roaming not allowed by server'

Re: OpenSSH: client bug CVE-2016-0777

#200

Earlier quoted context omitted.

ASLR makes exploits more difficult as long as you have true randomness. It is just a mitigation ... for another problem. In this case the elephant in the room is stack injection and dynamic libraries. If processes where confined to a well known address space that was self contained ASLR would be useless.. But dependency management would be hellish. Back to the case. OpenSSH has been openly criticize by 9plan teams fo…

What in the hell are you on about?

The base of science : critical thinking as opposed to expertise and "commonly accepted wisdom".

Trust, but check.

And if cannot check, I cannot trust.

Their map (model) is very nice, very detailed and self consistent. But is is not the territory (implementation) and the more complexity we stack the greater we prove the map diverge from the territory. And also the less it can be audited.

Don't expect normal people to trust what they cannot check. It is faith security experts are expecting from users, not trust.

I do my part of the contract as stated by common accepted risk management "best practice" regarding computer security.

I do not trust blindly.

Post reply on HN