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

211–220 of 226 posts

Re: OpenSSH: client bug CVE-2016-0777

#211

Post by the_mitsuhiko »

throwaway2048 wrote: post #196
the_mitsuhiko wrote: post #189

Earlier quoted context omitted.

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

If someone can actively MITM in your network you have other problems.

Re: OpenSSH: client bug CVE-2016-0777

#212

Post by throwaway2048 »

the_mitsuhiko wrote: post #211
throwaway2048 wrote: post #196

Earlier quoted context omitted.

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.

If someone can actively MITM in your network you have other problems.

That argument has been shown to be nonsense for years, it can apply to any mitigation technology or privilege reduction technique. The point is to reduce the amount of harm that can be done, because "just write software without bugs" isn't a solution at all.

Re: OpenSSH: client bug CVE-2016-0777

#213

Post by the_mitsuhiko »

throwaway2048 wrote: post #212
the_mitsuhiko wrote: post #211

Earlier quoted context omitted.

If someone can actively MITM in your network you have other problems.

That argument has been shown to be nonsense for years, it can apply to any mitigation technology or privilege reduction technique. The point is to reduce the amount of harm that can be done, because "just write software without bugs" isn't a solution at all.

> That argument has been shown to be nonsense for years, it can apply to any mitigation technology or privilege reduction technique. The point is to reduce the amount of harm that can be done, because "just write software without bugs" isn't a solution at all.

I don't disagree with this, but if you can MITM my traffic then impersonating SSH is the least of my worries. The chance that I will randomly SSH into a machine is pretty small to begin with whereas the deployment tools themselves for instance will push out code changes in regular intervals throughout the cluster. My point is: if you can actively MITM my traffic or anything similar in severity, then there are much more interesting targets than SSH.

Re: OpenSSH: client bug CVE-2016-0777

#214

Post by zackelan »

slasaus wrote: post #177

My hardened ~/.ssh/config on OS X 10.11: Host * Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 HostKeyAlgorithms ssh-ed25519,ssh-rsa ChallengeResponseAuthentication no UseRoaming no If you only conne…

> I assume using AEADs-only makes the MACs keyword obsolete, is this correct?

Correct. You can test this by running SSH with -v/--verbose and observing these log lines:

    debug1: kex: server->client aes256-gcm@openssh.com  none
    debug1: kex: client->server aes256-gcm@openssh.com  none
When using a cipher that does not support AEAD, the 2nd field will include the MAC instead of 

    debug1: kex: server->client aes256-ctr hmac-sha2-256-etm@openssh.com none
    debug1: kex: client->server aes256-ctr hmac-sha2-256-etm@openssh.com none
I wasn't sure what the 3rd "none" field is, but after some digging it appears to be the compression algorithm: https://github.com/openssh/openssh-portable/blob/master/kex....

And I confirmed this with ssh -C:

    debug1: kex: server->client aes256-ctr hmac-sha2-256-etm@openssh.com zlib@openssh.com
    debug1: kex: client->server aes256-ctr hmac-sha2-256-etm@openssh.com zlib@openssh.com

Re: OpenSSH: client bug CVE-2016-0777

#218

Post by Estragon »

d23 wrote: post #186
fixermark wrote: post #92

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

Yet another direct-link post to a cryptic CVE for those of us who aren't in the know on security issues. Upvoting is a great shibboleth to show that some posters "get it", while the rest of us are left in the dark on severity, left to wade through the comments section to try to get a sense of what the real impact is. From what I can tell, if I accidentally SSH to the wrong server (or a compromised one), my private ke…

Oh, come on. The issue is very clear. Your interpretation is correct.

Re: OpenSSH: client bug CVE-2016-0777

#220

Post by Gigablah »

jldugger wrote: post #145
tomjen3 wrote: post #140

Earlier quoted context omitted.

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.

I can't blame him, considering that people have been encouraging this sort of attitude towards the OpenSSL maintainers. It's time they tasted their own medicine.
Post reply on HN