openssh bugs - Apr 2017 - [Bug 2706] New: remote code execution via ProxyCommand+browser exploit

https://bugzilla.mindrot.org/show_bug.cgi?id=2706

            Bug ID: 2706
           Summary: remote code execution via ProxyCommand+browser exploit
           Product: Portable OpenSSH
           Version: 7.4p1
          Hardware: All
                OS: Mac OS X
            Status: NEW
          Severity: security
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: imoverclocked at gmail.com

Given the URL in a web browser: 

  "ssh://user at somehost.%60id%3E%2Ftmp%2Fwhoami%60.example.com"

iTerm2 currently launches ssh with a hostname of: 

  somehost.`id>/tmp/whoami`.example.com

With a vanilla SSH configuration this is ok since SSH errors out with
"host not found." However, with a special SSH configuration, a website
can execute an arbitrary command:

```
Host *
  ProxyCommand connect_to %r %h
```

What happened:

  `id>/tmp/whoami` was executed.

What should have happened instead:

1) SSH passes %r/%h as an argument to the ProxyCommand without shell
interpolation
2) %h should be validated to adhere to valid punycode
3) Introduce a SafeProxyCommand that only allows safe characters in
%r/%h/etc...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2706

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
ProxyCommand is explicitly documented as executing its commands via the
user's shell, and you've elected to use a ProxyCommand with no quoting.
E.g. 'ProxyCommand=connect_to "%r" "%h"' would have
been sufficient to
avoid this.

If you're going to plumb random string from potentially-adversarial
sources like a browser then you need to understand the contexts in
which they are going to end up used. Since ssh(1) doesn't handler
ssh:// URLs itself, you're already doing processing somewhere. That
would be the place for this sort of santisation.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2706

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.