Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
    
It's not a MiTM exploit, it's an untrusted server exploit. – Steve Sether Jan 14 at 19:19
    
@SteveSether: OK, thanks. This gets me closer to understanding it. It sounds like you could put that in an answer as opposed to a comment ;) – d33tah Jan 14 at 19: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.

share|improve this answer
7  
You don't mention it explicitly, but the attack requires connecting to a hostile server. – Mark Jan 14 at 21:57
    
Thanks for bringing that to my attention! – Mark Buffalo Jan 14 at 22:00
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 at 23:16
    
what if you use passwords and not keys? is it an issue then? – Sujay Phadke Apr 16 at 17:22

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.

share|improve this answer
    
Remote code execution is possible. Read the Qualys report. – Mark Buffalo Jan 14 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 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 at 20:13
1  
@dylan7 Whoops, I just read that again and noticed it's referring to OpenSSH >= 6.8 – Mark Buffalo Jan 14 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 at 21:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.