Bug 3515 - PermitRemoteOpen not behaving as expected
Summary: PermitRemoteOpen not behaving as expected
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 9.1p1
Hardware: amd64 Mac OS X
: P5 security
Assignee: Damien Miller
URL:
Keywords:
Depends on:
Blocks: V_9_2
  Show dependency treegraph
 
Reported: 2022-12-31 02:42 AEDT by Georges Chaudy
Modified: 2023-03-17 13:38 AEDT (History)
2 users (show)

See Also:


Attachments
don't consume first PermitRemoteOpen argument (2.39 KB, patch)
2022-12-31 11:17 AEDT, Damien Miller
dtucker: ok+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Georges Chaudy 2022-12-31 02:42:43 AEDT
Hello,

I am raising this as "security" because I am unsure if this is a bug or a feature. Sorry in advance if it's not a bug.

In short, I am struggling to restrict which hosts can be reached when using dynamic reverse forwarding. It seems that the PermitRemoteOpen option doesn't work as expected.

The documentation mentions :
```
RemoteForward: ... When acting as a SOCKS proxy, the destination of the connection can be restricted by PermitRemoteOpen.
```

Unrestricted works as expected
```
$ ssh -R 33000
$$ curl --socks5 localhost:33000 https://www.google.com -I
HTTP/1.1 200 OK
```

Prohibiting all forwarding requests every hosts works as expected
```
$ ssh -R 33000 -o PermitRemoteOpen none
$$ curl --socks5 localhost:33000 www.google.com -I
curl: (97) connection to proxy closed
```

Restricting access to t work
```
$ ssh -R 33000 -o PermitRemoteOpen example.com:443
$$ curl --socks5 localhost:33000 www.google.com -I
HTTP/1.1 200 OK <--- this should fail!
```
Comment 1 Damien Miller 2022-12-31 11:17:51 AEDT
Created attachment 3647 [details]
don't consume first PermitRemoteOpen argument

It's a bug. The parsing code for PermitRemoteOpen erroneously consumes its first argument to look for the special "any/none" keywords and doesn't record it if it isn't one of those.

We will be flagging this as a security bug in the next release.

Workaround: specify the first PermitRemoteOpen argument twice.

A separate problem is that we don't current have regression tests for PermitRemoteOpen
Comment 2 Damien Miller 2023-01-13 13:07:12 AEDT
This has been applied and will be in OpenSSH 9.2 - thanks!
Comment 3 Damien Miller 2023-03-17 13:38:11 AEDT
OpenSSH 9.3 has been released. Close resolved bugs