openssh bugs - May 2024 - [Bug 3686] New: Remote-forwarding of Unix socket not possible with `AllowStreamLocalForwarding remote` but `AllowTcpForwarding no`

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

            Bug ID: 3686
           Summary: Remote-forwarding of Unix socket not possible with
                    `AllowStreamLocalForwarding remote` but
                    `AllowTcpForwarding no`
           Product: Portable OpenSSH
           Version: 8.4p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: macdjord at gmail.com

As a user, my expectation is that the SSHD options
AllowStreamLocalForwarding and AllowTcpForwarding are independent, with
AllowStreamLocalForwarding controlling whether incoming connections are
allowed to forward to or from Unix sockets and AllowTcpForwarding
controlling whether incoming connections are allowed to forward to or
from TCP ports. However, I discovered, while attempting to configure a
system, that it is not possible to allow remote forwarding of Unix
sockets while prohibiting forwarding of TCP sockets.


The following tests were all conducted with the commands `ssh -v -R
'/var/REDACTED/REDACTED.sock:localhost:8010' -N my-server` and
`/usr/sbin/sshd -Ded`.


With `AllowStreamLocalForwarding no` and `AllowTcpForwarding remote` or
`no`, the behaviour was as expected: the forwarding failed with a
message that streamlocal forwarding had been disabled.

Relevant SSH output:
debug1: Remote: Server has disabled streamlocal forwarding.
debug1: remote forward failure for: listen
/var/REDACTED/REDACTED.sock:-2, connect localhost:8010
Error: remote port forwarding failed for listen path
/var/REDACTED/REDACTED.sock

Relevant SSHD output:
debug1: server_input_global_request: rtype
streamlocal-forward at openssh.com want_reply 1
debug1: server_input_global_request: streamlocal-forward listen path
/var/REDACTED/REDACTED.sock
debug1: server_input_global_request: rtype no-more-sessions at openssh.com
want_reply 0
Connection closed by 172.23.0.2 port 50362


With `AllowStreamLocalForwarding remote` and `AllowTcpForwarding
remote`, the behaviour was also as expected: the forwarding was
successful and the connection continued until terminated manually.

Relevant SSH output:
debug1: Remote connections from /var/REDACTED/REDACTED.sock:-2
forwarded to local address localhost:8010
debug1: ssh_init_forwarding: expecting replies for 1 forwards
debug1: Requesting no-more-sessions at openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00 at openssh.com
want_reply 0
debug1: Remote: /etc/sentinel_ssh/ssh_in-authorized_keys:1: key
options: command port-forwarding
debug1: Remote: /etc/sentinel_ssh/ssh_in-authorized_keys:1: key
options: command port-forwarding
debug1: remote forward success for: listen
/var/REDACTED/REDACTED.sock:-2, connect localhost:8010
debug1: forwarding_success: all expected forwarding replies received

Relevant SSHD output:
debug1: server_input_global_request: rtype
streamlocal-forward at openssh.com want_reply 1
debug1: server_input_global_request: streamlocal-forward listen path
/var/REDACTED/REDACTED.sock
debug1: Local forwarding listening on path /var/REDACTED/REDACTED.sock.
debug1: channel 0: new [unix listener]
debug1: server_input_global_request: rtype no-more-sessions at openssh.com
want_reply 0


But with `AllowStreamLocalForwarding remote` and `AllowTcpForwarding
no`, the behaviour was not as expected: the forwarding failed, with a
message that 'port forwarding refused'.

Relevant SSH output:
debug1: Remote: port forwarding refused
debug1: remote forward failure for: listen
/var/REDACTED/REDACTED.sock:-2, connect localhost:8010
Error: remote port forwarding failed for listen path
/var/REDACTED/REDACTED.sock

Relevant SSHD output:
debug1: server_input_global_request: rtype
streamlocal-forward at openssh.com want_reply 1
debug1: server_input_global_request: streamlocal-forward listen path
/var/REDACTED/REDACTED.sock
Received request from 172.23.0.2 port 53220 to remote forward to path
"/var/REDACTED/REDACTED.sock", but the request was denied.
debug1: server_input_global_request: rtype no-more-sessions at openssh.com
want_reply 0
Connection closed by 172.23.0.2 port 53220

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

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

Jordan Macdonald <macdjord at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macdjord at gmail.com

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

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

bugs-openssh at antipoul.fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs-openssh at antipoul.fr

--- Comment #1 from bugs-openssh at antipoul.fr ---
It's still happening in 9.6p1 at least.

I don't understand the permission logic, but it seems bogus.

In
https://github.com/openssh/openssh-portable/blob/master/channels.c#L4933
the function channel_connect_to_path checks permissions to match if
(path, PORT_STREAMLOCAL) is allowed, using open_match()

But open_match
(https://github.com/openssh/openssh-portable/blob/master/channels.c#L4413)
checks against port_to_connect, which is always -2 for unix socket
(https://github.com/openssh/openssh-portable/blob/master/misc.h#L155)

Of course it's not possible to specify negative port number in
PermitOpen directive (see
https://github.com/openssh/openssh-portable/blob/2c504a74ed81d13c8198a89ed1040d0fc5f73129/misc.c#L2053),
nor a path as a hostname.


I didn't dig into each details, but it seems that without
AllowTCPForwarding, AllowStreamLocalForwarding is useless. This could
be fixed by either:
- Mentioning in the documentation that AllowTcpForwarding is required
- Adding parsing for sockets in PermitListen and PermitOpen (which
would be the best ;) )

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