Since this is a client side issue, can this be used to exploit those automated scanners who try to break into your SSH machine?
[deleted]
OpenSSH: client bug CVE-2016-0777
81–90 of 226 posts
Re: OpenSSH: client bug CVE-2016-0777
#82Since this is a client side issue, can this be used to exploit those automated scanners who try to break into your SSH machine?
No. The scanners are looking for password-accessible accounts, not keyed accounts. The scanners won't have useful keys, nor listening ssh daemons.
Re: OpenSSH: client bug CVE-2016-0777
#83Use 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 future lose a box to the enemy, they can then use that box to grab your private key, and then use that key to get into every other box you can access with that keypair.
This turns your sysadmin's photo blog hosted on Digital Ocean into a potential vector into your entire infrastructure, since there is a high likelihood they use the same private key for both.
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.
You should expect adversaries to add an exploit for this to their rootkits. That would be bad enough since attackers targeting your infrastructure may exist, but this is also plausibly exploitable in a spray-and-pray fashion. Root any server on the Internet, using e.g. a WordPress vulnerability. Install key-stealing malicious SSH server. Forward all keys to your C&C infrastructure. Your infra does a reverse lookup from public key to Github account (trivial -- try "ssh whoami.filippo.io" if you don't believe me) and immediately optimistically tries to use the stolen key to log into the web tier of any site listed in their email/bio/Twitter profile/etc, pinging the attacker when it succeeds.
Re: OpenSSH: client bug CVE-2016-0777
#84ETA: I was way off... you can ignore this... :-) cf. section 3.3.5 [0], which describes "Roaming (Suspend/Resume)". This is documentation for an application by a company called AppGate (later acquired by Cryptzone) that wrote {some|most} of the code in OpenSSH's "roaming_client.c". This gives a hint of what the ramifications may be: basically, a MITM, who observed the initial session negotiation, can disconnect the c…
Oh Cryptzone, funny they offered me a job a few years back. Interesting that this was left in OpenSSH like this, even more as a default.
Re: OpenSSH: client bug CVE-2016-0777
#85theo must be mad. Shaming people for leaving useless non essential feature in their code that results in security breach. And now the jewel of his crown has been compromised. The funniest part is now that his jewel has been tarnished, maybe people will understand what he was saying. And maybe too, people that believed privacy can be achieved on the internet will finally look at the problem of believing the 2 general…
What Theo (and other OpenBSD developers) have been saying all these years is that it's impossible to /not/ make mistakes, which is why sane design and exploit mitigations are important.
Mad ? Maybe, I wouldn't know. On the other hand, I bet he's really glad all that effort to have ASLR by default was made, because it makes it more difficult for an attacker to exploit vulnerabilites such as this one.
Re: OpenSSH: client bug CVE-2016-0777
#86Does 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?
I came here to ask exactly this, and also why this feature isn't documented. Sounds like a nice little exploit.
Re: OpenSSH: client bug CVE-2016-0777
#87Earlier quoted context omitted.
Even easier, just place this text: UseRoaming no on its own line in your ~/.ssh/config file. If you don't have such a file, create it and put this line into it. Doing that will only protect you in that OS X user account, but I bet you only ever use one account on your Mac to SSH anyway.
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.
Re: OpenSSH: client bug CVE-2016-0777
#88Since this is a client side issue, can this be used to exploit those automated scanners who try to break into your SSH machine?
Authenticated scanners that use key auth like Qualys' security appliances could have private keys that are valid across the organization, and if using an affected client version, could leak this information to a malicious system on your network.
Re: OpenSSH: client bug CVE-2016-0777
#89Use 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…
This may be a start:
Host *
IdentityFile ~/.ssh/%h
Re: OpenSSH: client bug CVE-2016-0777
#90Does 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…
PuTTY is completely different code.