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

111–120 of 226 posts

Re: OpenSSH: client bug CVE-2016-0777

#111

Post by izolate »

robertcope wrote: post #102
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…

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.

Re: OpenSSH: client bug CVE-2016-0777

#112

Post by patio11 »

moviuro wrote: post #89
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…

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

It is not my understanding that SSH will attempt to use only the file identified by IdentityFile, and yes, that is surprising now isn't it. If the server does not cooperate with you, your proposed configuration will give the server all of the keys.

Edit to add: While I was testing this understanding (which is correct) mioelnir's comment added the setting you need to get the behavior which I thought was automatic.

Re: OpenSSH: client bug CVE-2016-0777

#113

Post by ryan-c »

moviuro wrote: post #89
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…

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

I have this:

    # IdentityFile magic, should be placed at very end of file
    Host *
    IdentityFile ~/.ssh/keys/id_ecdsa_%r@%h
    IdentityFile ~/.ssh/keys/id_rsa_%r@%h
    IdentityFile ~/.ssh/keys/id_ecdsa_ANY@%h
    IdentityFile ~/.ssh/keys/id_rsa_ANY@%h
    IdentityFile ~/.ssh/keys/id_ecdsa_%r@ANY
    IdentityFile ~/.ssh/keys/id_rsa_%r@ANY
    IdentityFile ~/.ssh/keys/id_ecdsa_ANY@ANY
    IdentityFile ~/.ssh/keys/id_rsa_ANY@ANY

Re: OpenSSH: client bug CVE-2016-0777

#114

Post by ryan-c »

robertcope wrote: post #102
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…

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.

If you want to stop this, require a specific, non-standard, RSA key size for each access group. They'll have to generate new keys. For ECC, maybe ssh certificates will work?

Re: OpenSSH: client bug CVE-2016-0777

#115

Post by SFjulie1 »

marios wrote: post #85
SFjulie1 wrote: post #61

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

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 for exactly the same reason openSSL has been criticized by openSSH team : too much complexity (not to say plan9 came to anything usable and were right (2 wrongs do not make a right)).

http://harmful.cat-v.org/software/ssh

I do have a feeling as a physicist that the S in CS stands for Shortness of thinking. What is obscure is not profound.

And, at the opposite of engineers I don't believe that security is achievable at all on computers. It is like believing there exists a way to avoid triangulation with one strong radio source.

Computers leak to much information (especially in the physical world), and C is a map that is taken too much for the territory. Every bugs are exploiting a wrong mapping of concepts to implementation.

Modern security is like string theory, admired by everyone because it requires great technical knowledge to master, understood by none because it is way to complex for our "human" brains. We live in an era of belief in solutions.

A bit of critical thinking and of distrusts of experts and stuff that you cannot understand without devoting your life to a subject is at my opinion a must.

I distrust mathematicians for their capacity of dealing with the real world and its uncertainties, and cryptography (as much as functional programming, big data, algorithmic, IA, machine learning) is math driven in a pure Aristotelian world. Where perfection and harmony is the pillar of thinking.

I come from micro-electronics, I only see wires (that are antennas), oscillators, multiplexers, gates and basically a dumb automat I can automatize in respect to time of propagation of signal, and I know that modern computers under the hood are in the physical realm of relativity with approximate answers.

I theorize, build, measure, and retheorize ad nauseum until the product is measured to work the way I expect it to in the domain of validity with a good enough confidence and margins of errors are always on my mind to be controled.

Security requires a zero margin of ambiguity. Physical world is bound to heisenberg equation and coupling. Purity does not exist and this cannot be mitigated. The postulate of cryptography are wrong from the core. Real world always win at the end.

Aristotle way of thinking must die. Math is not science.

Re: OpenSSH: client bug CVE-2016-0777

#117

Post by mioelnir »

izolate wrote: post #111
robertcope wrote: post #102

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.

For the at-work keys, I differentiate between work/workstation and work/laptop. Full disk encryption and the bcrypt based ssh private key format hopefully buy me enough time to revoke the laptop keys and have a KRL update pushed to all servers if it gets stolen.

Re: OpenSSH: client bug CVE-2016-0777

#118

Post by feld »

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? :)

Re: OpenSSH: client bug CVE-2016-0777

#120

Post by aexaey »

mioelnir wrote: post #107
moviuro wrote: 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

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

Post reply on HN