I recently heard about a serious bug in an OpenSSH client (CVE-2016-0777 and CVE-2016-0778) that if I understood correctly could cause remote code execution. How difficult would be for an active man-in-the-middle to exploit that?
Like Steve Sether said, this is not a man-in-the-middle attack.
How dangerous is it?
- In some cases, buffer overflow attacks are possible.
- Your private SSH keys can be leaked to an attacker.
According to the page:
SSH roaming enables a client, in case an SSH connection breaks unexpectedly, to resume it at a later time, provided the server also supports it. The OpenSSH server doesn't support roaming, but the OpenSSH client supports it (even though it's not documented) and it's enabled by default.
For starters, this feature is enabled by default in OpenSSH. Even worse, it is undocumented in the
ssh_config(5) man page.
Note that this is two exploits:
- An information leak (memory disclosure) can be exploited by a rogue SSH server to trick a client into leaking sensitive data from the client memory, including for example private keys.
- A buffer overflow (leading to file descriptor leak), can also be exploited by a rogue SSH server, but due to another bug in the code is possibly not exploitable, and only under certain conditions (not the default configuration), when using ProxyCommand, ForwardAgent or ForwardX11.
Regarding the buffer overflow attack, note that it's only vulnerable under certain conditions, when you have ProxyCommand, and ForwardAgent or ForwardX11 enabled. Those are non-default options, so while it's possible it won't be exploited in a large majority of cases, it is possible.
In the case of a successful buffer overflow attack, assume everything accessible by the SSH client is breached.
I would read the Qualys Analysis. This paper will explain this attack in great detail far better than most of us, including myself.
could cause remote code execution
No remote code execution. No man-in the middle as it was cleared up by Mark. Everything is explained in the Qualys analysis as already linked.
But in short:
The vulnerable thing is implementation of the Roaming feature in client. Client stores buffer of not send bytes if the connection is suspended. The vulnerable, badly crafted server can force the client to resend more than is in the buffer and therefore he might get your private key, if it is actually stored on some addresses around (should not be in normal case).
The analysis is presented on specific version (openssh-6.4), which is almost nowhere used today and most of the use cases are not directly applicable to currently used versions. Also some of the problems are specific to BSD systems, where the memory zeroing was not working as expected. I didn't manage to get any of the keys on any current systems I had around.
The biggest problem is the thing that there even was such a thing, undocumented feature, which was vulnerable in such form. And that it was there for so long (introduced in 2004) and that it was turned on by default. This might have been misused in past, but not without the knowledge of the user (if the session was interactive). If you would see
[connection suspended, press return to resume]
I guess you would get a bit suspicious.