3 ms·

Roaming through the OpenSSH client: CVE-2016-0777 and 0778

88 points by jlgaddis 11y ago

rvern 11y ago
Summary: – The vulnerability allows a server you connect to to get the contents of the memory of the OpenSSH client. – If your keys are not protected by a passphrase or you do not use ssh-agent, this can include private keys. – OpenSSH 5.4 to 7.1 are affected. – You can mitigate this by adding "UseRoaming no" to /etc/ssh/ssh_config or ~/.ssh/config. – You should change your SSH keys.
- bluegate010 11y ago
  > If your keys are not protected by a passphrase Looks like the private key can be leaked regardless of the use of a passphrase, but you'd get the encrypted form that would need to be cracked offline.
drostie 11y ago
The most interesting part of this disclosure is: Internal stdio buffering is the most severe of the three problems discussed in this section, although GNU/Linux is not affected because the glibc mmap()s and munmap()s (and therefore cleanses) stdio buffers. BSD-based systems, on the other hand, are severely affected because they simply malloc()ate and free() stdio buffers. Basically the exploit reveals a big chunk of memory where, very often, your private keys happen to live. The memory has been freed, but on BSD systems the memory that was freed has not been zeroed in any way, so you still see the private keys.
- abstractbeliefs 11y ago
  So basically, the end result is that we have heartbleed for SSH? While the cause is slightly different, the ultimate effect is an attacker being able to read significant chunks of memory remotely, which for SSH often means private key details.
  - drostie 11y ago
    Not quite. With apologies to Missy Elliott: It needs the client, to be served it. It's Heartbleed if you flip it and reverse it. [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] If you SSH in, we can search it And if you're roaming, steal your private key bits [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] B, B, on BSD or any platform with a bad libc [Why-thai,-thai-o-toy-o-thai-thai] [Why-thai,-thai-o-toy-o-thai-thai] 'Cause, they, don't zero bits, Not that anyone expected it. 'Aint no shame, Libc, do your thang, OpenSSH's do-nothing feature here is to blame.
    - rconti 11y ago
      golf clap
kevincox 11y ago
On another note are there any plans to implement Roaming in the server? Because vulnerabilities aside it sounds like an awesome feature and I would use it all the time.
- kardos 11y ago
  That seems incredibly unlikely. Also maybe mosh [1] will do that for you. [1] https://mosh.mit.edu/ https://mosh.mit.edu/

88 points by jlgaddis 11y ago

rvern 11y ago

Summary: – The vulnerability allows a server you connect to to get the contents of the memory of the OpenSSH client. – If your keys are not protected by a passphrase or you do not use ssh-agent, this can include private keys. – OpenSSH 5.4 to 7.1 are affected. – You can mitigate this by adding "UseRoaming no" to /etc/ssh/ssh_config or ~/.ssh/config. – You should change your SSH keys.

bluegate010 11y ago
> If your keys are not protected by a passphrase Looks like the private key can be leaked regardless of the use of a passphrase, but you'd get the encrypted form that would need to be cracked offline.

drostie 11y ago

The most interesting part of this disclosure is: Internal stdio buffering is the most severe of the three problems discussed in this section, although GNU/Linux is not affected because the glibc mmap()s and munmap()s (and therefore cleanses) stdio buffers. BSD-based systems, on the other hand, are severely affected because they simply malloc()ate and free() stdio buffers. Basically the exploit reveals a big chunk of memory where, very often, your private keys happen to live. The memory has been freed, but on BSD systems the memory that was freed has not been zeroed in any way, so you still see the private keys.

abstractbeliefs 11y ago
So basically, the end result is that we have heartbleed for SSH? While the cause is slightly different, the ultimate effect is an attacker being able to read significant chunks of memory remotely, which for SSH often means private key details.
- drostie 11y ago
  Not quite. With apologies to Missy Elliott: It needs the client, to be served it. It's Heartbleed if you flip it and reverse it. [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] If you SSH in, we can search it And if you're roaming, steal your private key bits [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] [.ti esrever dna ti pilf uoy fi deelbtraeH s'tI] B, B, on BSD or any platform with a bad libc [Why-thai,-thai-o-toy-o-thai-thai] [Why-thai,-thai-o-toy-o-thai-thai] 'Cause, they, don't zero bits, Not that anyone expected it. 'Aint no shame, Libc, do your thang, OpenSSH's do-nothing feature here is to blame.
  - rconti 11y ago
    golf clap

kevincox 11y ago

On another note are there any plans to implement Roaming in the server? Because vulnerabilities aside it sounds like an awesome feature and I would use it all the time.

kardos 11y ago
That seems incredibly unlikely. Also maybe mosh [1] will do that for you. [1] https://mosh.mit.edu/ https://mosh.mit.edu/