25

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?

d33tah
  • 6,524
  • 8
  • 38
  • 60

2 Answers2

24

Like Steve Sether said, this is not a man-in-the-middle attack.

How dangerous is it?

  1. In some cases, buffer overflow attacks are possible.
  2. 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:

  1. CVE-2016-0777
    • 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.
  2. CVE-2016-0778
    • 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.

More Information

I would read the Qualys Analysis. This paper will explain this attack in great detail far better than most of us, including myself.

Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
  • 7
    You don't mention it explicitly, but the attack requires connecting to a hostile server. – Mark Jan 14 '16 at 21:57
  • 2
    Buffer Overflow, leaks private key, enabled by default, "assume everything is breached if successful", open source secure connection software with a dormant bug that noone noticed for years,... Is it me, or does this sound a lot like what happened in April 2014 with OpenSSL and Heartbleed? – Nzall Jan 14 '16 at 23:16
  • what if you use passwords and not keys? is it an issue then? – Sujay Phadke Apr 16 '16 at 17:22
10

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.

Community
  • 1
Jakuje
  • 5,229
  • 16
  • 31
  • Remote code execution is possible. Read the Qualys report. – Mark Buffalo Jan 14 '16 at 20:08
  • @MarkBuffalo can you point out where and how? I read it quite in detail. I do not see there any mention of remote code execution. – Jakuje Jan 14 '16 at 20:11
  • 1
    It's possible I've mixed it up, but I consider most buffer overflows to be remote code execution, as they're often executed by a remote attacker. – Mark Buffalo Jan 14 '16 at 20:13
  • @MarkBuffalo This is just the case when your server can read memory from your client. Without writing so without execution. – Jakuje Jan 14 '16 at 20:14
  • The paper seems to say that no RCE can occur due to a bug: "As a result, the global pointer backup_state is still NULL when passed to ssh_packet_restore_state(), and crashes the OpenSSH client when dereferenced:... This bug prevents the buffer overflow from being exploited, but not the information leak,..." – dylan7 Jan 14 '16 at 20:59
  • 1
    @dylan7 Whoops, I just read that again and noticed it's referring to OpenSSH >= 6.8 – Mark Buffalo Jan 14 '16 at 21:23
  • 2
    @Mark Buffalo Ah yes specific to those versions, I missed that: "This buffer overflow affects all OpenSSH clients >= 5.4, but its impact is significantly reduced by the Mitigating Factors detailed in the Information Leak section". – dylan7 Jan 14 '16 at 21:29