Hello folks,
you should do an
echo 'UseRoaming no' >> /etc/ssh/ssh_config
to secure your system according to http://undeadly.org/cgi?action=article&sid=20160114142733
Do not aks me for details. I'm just redistributing the warning.
--Frank
On 01/14/2016 10:35 AM, Frank Elsner wrote:
Hello folks,
you should do an
echo 'UseRoaming no' >> /etc/ssh/ssh_config
to secure your system according to http://undeadly.org/cgi?action=article&sid=20160114142733
Do not aks me for details. I'm just redistributing the warning.
--Frank
Also, it would be prudent to rotate your keys, as this bug has been present since 2009.
On Thu, 2016-01-14 at 14:05 -0600, Dan Mossor wrote:
Also, it would be prudent to rotate your keys, as this bug has been present since 2009.
"Rotating your keys," sounds kind of humourous. ;-)
This shows just one advantage of doing fresh installs, instead of updates. Those of use who do fresh installs, won't have old keys from prior releases still on our systems.
On 01/15/2016 03:51 AM, Tim wrote:
This shows just one advantage of doing fresh installs, instead of updates. Those of use who do fresh installs, won't have old keys from prior releases still on our systems.
"Your keys" means your private authentication keys. The ones in ~/.ssh. If you keep or restore your home directory, it doesn't matter if you do a fresh install or an upgrade. I have a hard time imagining any significant number of people disposing of all of their data every time they update Fedora.
Tim:
This shows just one advantage of doing fresh installs, instead of updates. Those of use who do fresh installs, won't have old keys from prior releases still on our systems.
Gordon Messmer:
"Your keys" means your private authentication keys. The ones in ~/.ssh. If you keep or restore your home directory, it doesn't matter if you do a fresh install or an upgrade. I have a hard time imagining any significant number of people disposing of all of their data every time they update Fedora.
I do. I don't carry over any of the hidden config files, from one release to another. Just my own work.
Long ago, I found that carrying over any baggage from a prior release risks carrying over problems that were fixed with a new release, or adding new problems by incorporating incompatible configuration settings.
I would suspect that a lot of people who do new installs and simply back-up and restore personal files, or drag and drop them, don't bother with the hidden files. Some will, of course. And a few are aware of potential problems by doing so.
On Thu, 14 Jan 2016 17:35:10 +0100 Frank Elsner frank@moltke28.B.Shuttle.DE wrote:
you should do an
echo 'UseRoaming no' >> /etc/ssh/ssh_config
to secure your system according to http://undeadly.org/cgi?action=article&sid=20160114142733
Thanks for the heads up.
On Thu, Jan 14, 2016 at 8:35 AM, Frank Elsner frank@moltke28.b.shuttle.de wrote:
you should do an echo 'UseRoaming no' >> /etc/ssh/ssh_config
Depending on the content of your ssh_config file, that might not be an effective fix. The recommended mitigation is:
# echo -e 'Host *\nUseRoaming no' >> /etc/ssh/ssh_config
to secure your system according to http://undeadly.org/cgi?action=article&sid=20160114142733
For the sake of conversation...
Reading the Qualys security advisory is interesting as well, and I tend to think the vulnerability is not severe for a number of reasons: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-20...
First, because versions 5.4 - 5.6 were not vulnerable to the information leak on GNU/Linux, though they were on BSD systems. Second, because later versions may have been able to leak private keys, but only incomplete copies of them. Last, because encrypted keys could only be leaked in their encrypted form, and keys used with an ssh-agent were not vulnerable to leaking at all.
The buffer overflow vulnerability seems more severe, but only if you're using a bastion host which is compromised. The vulnerability can only be triggered when using ProxyCommand. The buffer overflow also is not exploitable on OpenSSH 6.8, due to a bug introduced in that version.
-
Dan Mossor -
Frank Elsner -
Gordon Messmer -
stan -
Tim