Live data from Hacker News

OpenSSH: client bug CVE-2016-0777

undeadly.org

171–180 of 226 posts

Re: OpenSSH: client bug CVE-2016-0777

#171

Earlier quoted context omitted.

I really hope that sysadmins/people are not using the same private key for work and pleasure. And for that matter, the same key at work for DEV/TEST/PROD. But you're probably right that a lot of them are.

Depends how you look at it. I use my key pair as my digital identification, whether at work or at home. I only have the one set. That logic held up until now I suppose, with the leaking of private keys.

It does depend. This may be leftover behavior from my contract days, but I've always had at least one key per entity with which I interact[1].

The reasoning is that it is far easier for me (or the entity, but that's a bit different) to delete one keyfile to sever access than it is for me to rekey everything else. I don't want access to things I'm not actively engaged with - compromises happen, even to engineers' laptops, and that conversation with former employers is too much like calling up your exes to tell them about a VD test result for my comfort.

As far as it being digital identification, lots of companies have IDs separate from your DL/passport. This is usually because the company ID provides access to something your other ID doesn't. Same principle.

[1] There are lots reasons to have lots of different keys, and only having one per entity is pretty rare for me.

Re: OpenSSH: client bug CVE-2016-0777

#172

Earlier quoted context omitted.

> But if you use an agent, the client never loads the private key, so it's safe from memory disclosure vulnerabilities. This is what I would assume, but has it been confirmed that this vulnerability doesn't affect identities provided by an SSH agent? If any of this "roaming" support was provided by the agent, it could be the case that the leakage can be triggered via SSH agent protocol requests. I doubt this is the c…

The main issue identified by Qualys is a more generic memory disclosure bug: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077... This means they are basically able to dump the memory of just the running `ssh` process -- eerily similar to Heartbleed. This means private keys stored by the `ssh-agent` process, outside of the `ssh` process connecting to an Evil Server(TM) are not affected. This is because the…

Good to know. Note regarding your final sentence, however: this design does not necessarily prevent the SSH agent from having a bug which can cause key disclosure via the agent protocol. It returns data buffers, so if it could be tricked into leaking key material into those data buffers, it may end up getting sent back to the server just the same (e.g. as a signature value). This would, however, be a bug in the agent and not the client.

Re: OpenSSH: client bug CVE-2016-0777

#173
I'm curious how typo and bit squatting would come into play here, and if attacks leveraging them could collect private keys at a dangerously high rate before people can patch their clients.

Products like heroku, or the stripe CTF, or other things that come to mind that operate over SSH going rogue a bit scarier. If one were to be compromised it would be a case where mass amounts of private keys could leak. AWS, github, all cloud VPS providers, etc.

Multifactor is relevant as a defense with a vulnerability like this.

Re: OpenSSH: client bug CVE-2016-0777

#174
post #122

Earlier quoted context omitted.

> 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. A better mandate would be to use ssh-agent. Using separate key pairs without an agent doesn't prevent key theft due to memory disclosure vulnerabilities like this one; it merely compartmentalizes the damage. But if you use an ag…

> But if you use an agent, the client never loads the private key, so it's safe from memory disclosure vulnerabilities. This is what I would assume, but has it been confirmed that this vulnerability doesn't affect identities provided by an SSH agent? If any of this "roaming" support was provided by the agent, it could be the case that the leakage can be triggered via SSH agent protocol requests. I doubt this is the c…

The Qualsys analysis states that keys provided by an agent are not disclosed, and that encrypted keys are disclosed in their encrypted form.

https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...

Quoting from above: Finally, for these three reasons, passphrase-encrypted SSH keys are leaked in their encrypted form, but an attacker may attempt to crack the passphrase offline. On the other hand, SSH keys that are available only through an authentication agent are never leaked, in any form.

So if you use an agent, and follow the good advice to encrypt your private keys you should be safe(er).

See for older client versions:

http://martin.kleppmann.com/2013/05/24/improving-security-of...

or better for newer clients:

http://www.tedunangst.com/flak/post/new-openssh-key-format-a...

Re: OpenSSH: client bug CVE-2016-0777

#175
post #173

I'm curious how typo and bit squatting would come into play here, and if attacks leveraging them could collect private keys at a dangerously high rate before people can patch their clients. Products like heroku, or the stripe CTF, or other things that come to mind that operate over SSH going rogue a bit scarier. If one were to be compromised it would be a case where mass amounts of private keys could leak. AWS, githu…

[deleted]

Re: OpenSSH: client bug CVE-2016-0777

#176
Some good news was added to the updates:

> The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, private keys are not exposed to clients using the agent.

Re: OpenSSH: client bug CVE-2016-0777

#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 connect to newer servers you can further restrict ciphers to only use AEADs (only list the chacha20-poly1305 and aes-gcm ciphers). I assume using AEADs-only makes the MACs keyword obsolete, is this correct?

Config is based on tips from https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

Re: OpenSSH: client bug CVE-2016-0777

#178

Just a note: the default AWS Linux AMI doesn't seem to have this problem on the server side. Connecting to one of my EC2 instances with verbose on I get the following message: debug1: Roaming not allowed by server Yeah! AWS Linux for the win. :)

[deleted]

Re: OpenSSH: client bug CVE-2016-0777

#179

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…

Mozilla also maintains a SSH guide for both clients and servers: https://wiki.mozilla.org/Security/Guidelines/OpenSSH

Re: OpenSSH: client bug CVE-2016-0777

#180
post #169

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)

Interestingly I haven't been able to get the Roaming not allowed message to show on my client with or without the config option set.

Did you copy the whole line as "g ssh -v -T git@github.com 2>&1 | grep "Roaming debug1: Roaming not allowed by server"" ?

I misread GP's command and made that mistake. The correct command is :

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

Post reply on HN