Bug 2706 - remote code execution via ProxyCommand+browser exploit
Summary: remote code execution via ProxyCommand+browser exploit
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 7.4p1
Hardware: All Mac OS X
: P5 security
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-07 13:31 AEST by imoverclocked
Modified: 2021-04-23 15:00 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description imoverclocked 2017-04-07 13:31:37 AEST
Given the URL in a web browser: 

  "ssh://user@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...
Comment 1 Damien Miller 2017-06-02 15:03:54 AEST
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.
Comment 2 Damien Miller 2021-04-23 15:00:59 AEST
closing resolved bugs as of 8.6p1 release