openssh bugs - May 2020 - [Bug 3159] New: authorized_keys: gap in port forwarding restrictions

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

            Bug ID: 3159
           Summary: authorized_keys: gap in port forwarding restrictions
           Product: Portable OpenSSH
           Version: 8.0p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: spmfox at foxwd.com

I believe I have found a gap in the implementation of the port
forwarding restrictions. I've been testing this on CentOS Linux release
8.1.1911 + OpenSSH_8.0p1, OpenSSL 1.1.1c FIPS  28 May 2019.

Currently we have the following options to restrict port forwarding in
the authorized_keys file:

---
restrict: Enable all restrictions
no-port-forwarding: Forbids TCP forwarding when this key is used for
authentication.
port-forwarding: Enable port forwarding previously disabled by the
restrict option.
permitopen: Limit local port forwarding with the ssh(1) -L option such
that it may only connect to the specified host and port.
permitlisten: Limit remote port forwarding with the ssh(1) -R option
such that it may only listen on the specified host (optional) and port.
---

If you enable 'restrict' or 'no-port-forwarding', it does not
matter if
you also use 'permitopen' or 'permitlisten' - all port
forwarding
requests are still denied. Assuming 'restrict' is in use, if you want
to enable port forwarding you must also use 'port-forwarding'. At this
point, all port forwarding (local and remote) are allowed.

Assume you only want one remote port allowed, "localhost:5000". If you
use 'permitlisten=localhost:5000', you will restrict all other remote
ports from being opened - only allowing that one. However you leave the
local port forwarding wide open.

There is no easy way to lock down both local and remote port
forwarding, if you are using one and not the other, since they cannot
be disabled/enabled individually.

================Examples:
(restrict,command="echo 'Port forwarding only
account.'",permitlisten="localhost:5000")
Logically, this looks like we've enabled every restriction, then
allowed one remote port forward. This will *not* work at all, since
'port-forwarding' isn't specified.
==(restrict,command="echo 'Port forwarding only
account.'",port-forwarding,permitlisten="localhost:5000")
Now we've enabled port forwarding, and it looks like we've locked it
down to one remote port. This will work, however *local port forwarding
is wide open* - in fact, this will even allow unrestricted dynamic port
forwarding as well.
==(restrict,command="echo 'Port forwarding only
account.'",port-forwarding,permitlisten="localhost:5000",permitopen:"localhost:22")
This is the only way I found to restrict local AND remote forwarding,
when you only really want to use remote. Assuming local port 22 is
already exposed (since you're connecting to it) we can specify that
port and that will block all other requests.
================
My personal opinion is: Keep 'restrict', 'no-port-forwarding',
and
'port-forwarding' the same, however when you use 'permitlisten or
'permitopen' its automatically exempt from 'restrict' or
'no-port-forwarding'. This would allow you to do a blanket restriction,
and then open local or remote ports as-needed while still giving the
option to block or also allow all ports local or remote.

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

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

spmfox at foxwd.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spmfox at foxwd.com

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