January 14, 201610 yr http://undeadly.org/cgi?action=article&sid=20160114142733 As it stands this looks like it will be an urgent fix to deploy. * SECURITY: ssh(1): The OpenSSH client code between 5.4 and 7.1 contains experimential support for resuming SSH-connections (roaming). The matching server code has never been shipped, but the client code was enabled by default and could be tricked by a malicious server into leaking client memory to the server, including private client user keys. The authentication of the server host key prevents exploitation by a man-in-the-middle, so this information leak is restricted to connections to malicious or compromised servers. MITIGATION: For OpenSSH >= 5.4 the vulnerable code in the client can be completely disabled by adding 'UseRoaming no' to the gobal ssh_config(5) file, or to user configuration in ~/.ssh/config, or by passing -oUseRoaming=no on the command line.
January 15, 201610 yr http://undeadly.org/cgi?action=article&sid=20160114142733 As it stands this looks like it will be an urgent fix to deploy. * SECURITY: ssh(1): The OpenSSH client code between 5.4 and 7.1 contains experimential support for resuming SSH-connections (roaming). The matching server code has never been shipped, but the client code was enabled by default and could be tricked by a malicious server into leaking client memory to the server, including private client user keys. The authentication of the server host key prevents exploitation by a man-in-the-middle, so this information leak is restricted to connections to malicious or compromised servers. MITIGATION: For OpenSSH >= 5.4 the vulnerable code in the client can be completely disabled by adding 'UseRoaming no' to the gobal ssh_config(5) file, or to user configuration in ~/.ssh/config, or by passing -oUseRoaming=no on the command line. While we will patch this, it's actually not as urgent as you think. This is an SSH CLIENT issue, not a server issue. While we do include the ssh client with unRAID, the bug is only relevant if you are using it to initiate an SSH session from unRAID to another system, which isn't something we directly support or suggest (it would require you to login via command line to do this). Connections TO unRAID from other devices does not make unRAID vulnerable to this bug.
January 15, 201610 yr Keep in mind that some people use rsync over ssh to remote servers locally and over the internet (and over a VPN).
January 15, 201610 yr Keep in mind that some people use rsync over ssh to remote servers locally and over the internet (and over a VPN). Which is why we will patch it, but that isn't technically something we directly support or even suspect a large percentage of our users to be doing. Just trying to highlight the difference in criticalness between this type of bug that only affects a few extra savvy users compared to the majority that restrict themselves to the confines our what unRAID OS provides through the webgui.
January 16, 201610 yr Just an FYI, this is now patched in 6.1.7!! Hoping to see a release tonight!! soon™ has been retired ?
January 16, 201610 yr Author Just an FYI, this is now patched in 6.1.7!! Hoping to see a release tonight!! Good news. However can you confirm this as openssh (SSA:2016-014-01) was not in the release notes
January 16, 201610 yr Just an FYI, this is now patched in 6.1.7!! Hoping to see a release tonight!! Good news. However can you confirm this as openssh (SSA:2016-014-01) was not in the release notes Yes, Eric caught we missed that in the release notes but its actually there.
January 18, 201610 yr Author Please update the release notes to close down this CVE as complete and solved. Compliments on the fast turn around.
January 26, 201610 yr Author Polite 8 day bump. LT official release notes do not document this patch. Marking as fixed as dedicated release note bug posted here http://lime-technology.com/forum/index.php?topic=45799.0
Archived
This topic is now archived and is closed to further replies.