Does this affect mosh?
OpenSSH: client bug CVE-2016-0777
31–40 of 226 posts
Re: OpenSSH: client bug CVE-2016-0777
#32Someone tweeted this, the roaming code doesn't seem to be very well managed: https://twitter.com/marver/status/687644904575627264 Edit 1: Here's some relevant commits too https://marc.info/?l=openbsd-cvs&m=145278217421101&w=2 Edit 2: This mailing list post seems to discuss the vulnerable feature http://www.gossamer-threads.com/lists/openssh/dev/49018?do=p... Edit 3: Got a better description of actual impact of the bu…
> >server, potentially leaking key material. CVE-2016-077 and CVE-0216-078. Presumably you meant CVE-2016-0777 and CVE-2016-0778
I'm just quoting OFFICIAL SOURCES here.
Re: OpenSSH: client bug CVE-2016-0777
#33Does this affect mosh?
No, the roaming in Mosh is unrelated to OpenSSH's roaming feature.
Re: OpenSSH: client bug CVE-2016-0777
#34Does it strike anyone else as bizarre / poor form for an experimental feature to be enabled by default in OpenSSH, which is normally very conservative with option defaults?
Re: OpenSSH: client bug CVE-2016-0777
#35Someone tweeted this, the roaming code doesn't seem to be very well managed: https://twitter.com/marver/status/687644904575627264 Edit 1: Here's some relevant commits too https://marc.info/?l=openbsd-cvs&m=145278217421101&w=2 Edit 2: This mailing list post seems to discuss the vulnerable feature http://www.gossamer-threads.com/lists/openssh/dev/49018?do=p... Edit 3: Got a better description of actual impact of the bu…
So the real question is, can a MITM intercept connections to boxen you frequent to exploit this? Or is it limited to connecting to hostile honeypots?
Tested quickly, doesn't look like it. Host key checking happens before the roaming stuff.
That doesn't mean it's limited to hostile honeypots, if it turns out that this is easily exploitable it'll be a complete shitstorm with sysadmins getting owned left and right with rootkits implementing automatic exploitation.
Re: OpenSSH: client bug CVE-2016-0777
#36Workaround (yes, it's client-side): # echo -e "Host *\n\tUseRoaming no\n" >> /etc/ssh/ssh_config Disclaimer: won't work on all operating systems, shells, etc. YMMV. Consult a doctor before following any advice you get from the Internet. Void where prohibited. Restrictions may apply. Edited per comments below
Presumably you would have to connect to a malicious host to be effected? Or perhaps a MITM on your connection to a legit host can exploit you somehow.
From the updated OP:
> 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.
Re: OpenSSH: client bug CVE-2016-0777
#37What was this experimental / undocumented roaming feature even suppose to do?
Re: OpenSSH: client bug CVE-2016-0777
#38Someone tweeted this, the roaming code doesn't seem to be very well managed: https://twitter.com/marver/status/687644904575627264 Edit 1: Here's some relevant commits too https://marc.info/?l=openbsd-cvs&m=145278217421101&w=2 Edit 2: This mailing list post seems to discuss the vulnerable feature http://www.gossamer-threads.com/lists/openssh/dev/49018?do=p... Edit 3: Got a better description of actual impact of the bu…
So the real question is, can a MITM intercept connections to boxen you frequent to exploit this? Or is it limited to connecting to hostile honeypots?
[deleted]
Re: OpenSSH: client bug CVE-2016-0777
#39ETA: I was way off... you can ignore this... :-)
cf. section 3.3.5 [0], which describes "Roaming (Suspend/Resume)". This is documentation for an application by a company called AppGate (later acquired by Cryptzone) that wrote {some|most} of the code in OpenSSH's "roaming_client.c".
This gives a hint of what the ramifications may be: basically, a MITM, who observed the initial session negotiation, can disconnect the client and hijack an active session.
> Roaming is a feature which allows clients to suspend the connection to the AppGate server and later to resume it again. The user does not need to re-authenticate when reconnecting. Indeed, the entire process can be completely automated and nearly invisible to the user. All established connections will remain alive while roaming. This feature is intended for mobile users who move around between networks.
> Technically, roaming is accomplished by closing the TCP tunnel when the connection is suspended. When resuming, a new TCP connection is made to the server and the SSH data stream is continued through this new connection. The user does not need to authenticate again, instead the client authenticates to the server, without user interaction, with the help of a random password which was made up when the user authenticated at the start of the session. In addition to knowing this password, the client must also know the encryption keys and encryption state to be able to reconnect. It is therefore impossible for a third party to break in and take over a suspended session.
I particularly like that last sentence.
[0]: http://download.cryptzone.com/files/download/AppGate-10.2.3/...
Re: OpenSSH: client bug CVE-2016-0777
#40Someone tweeted this, the roaming code doesn't seem to be very well managed: https://twitter.com/marver/status/687644904575627264 Edit 1: Here's some relevant commits too https://marc.info/?l=openbsd-cvs&m=145278217421101&w=2 Edit 2: This mailing list post seems to discuss the vulnerable feature http://www.gossamer-threads.com/lists/openssh/dev/49018?do=p... Edit 3: Got a better description of actual impact of the bu…
So the real question is, can a MITM intercept connections to boxen you frequent to exploit this? Or is it limited to connecting to hostile honeypots?
Apparently not possible with MITM.
"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."
https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-Ja...