sshd_config AllowStreamLocalForwarding perm off / effectively privsep off

sshd_config AllowStreamLocalForwarding perm off / effectively privsep off

[Shaddy Baddah]

Hi,

For the current OpenSSH server (9.3p2),  AllowStreamLocalForwarding
defaults on. That means both local and remote unix socket port
portforwarding are possible.

For Cygwin, it appears the remote form of this is not possible. The
following message is seen on the client-side, regardless of whether
sshd_config explicitly defines AllowStreamLocalForwarding "on", or
"all":

|Forwarding port.
|debug1: Remote: Server has disabled streamlocal forwarding.

Finding the code around this, and a three(?) component conditional
expression that "fails" into that message, I discovered that the
reason it is not allowed is the following conditional:

|		    (pw->pw_uid != 0 && !use_privsep)) {

and to my surprise, after compiling a debug version of sshd to discover
this conditional, it turns out that use_privsep is set to zero (0).

I've been around the Cygwin community for many years, and I remember
the time when ssh-host-config prompted for priv sep, and the creation
of the "sshd" local user.

I remember the transition when that prompt was removed, and reading that
priv sep was now "on permanently".

I think there is a misunderstanding here though, though I'm not 100%
sure of my reading of the situation. It appears that though priv sep is
on by default, for Cygwin, it is effectively off, as it cannot be
implemented???

Because this bit of code from sshd.c suggests if DISABLE_FD_PASS is set,
then use_privsep needs to be set to false:

|#ifdef DISABLE_FD_PASSING
|	if (1) {
|#else
|	if (authctxt->pw->pw_uid == 0) {
|#endif
|		/* File descriptor passing is broken or root login */
|		use_privsep = 0;
|		goto skip;

DISABLE_FD_PASS is always set by autoconf for Cygwin. And my reading is
that not having that capability effectively means whatever the other
criteria, the executing process doesn't have sufficient "separation" of
privilege to be treated in the same manner.

Otherwise, what's the solution? Because the reason for the earlier guard
(the disallowal of streamlocal) was a fix for a CVE from very long ago,
that allowed unix-sockets to be created on the server as
"root"/privileged user.

-- 
Regards,
Shaddy

Re: sshd_config AllowStreamLocalForwarding perm off / effectively privsep off

[Corinna Vinschen]

On Aug  7 22:11, Shaddy Baddah via Cygwin wrote:
> Hi,
> 
> For the current OpenSSH server (9.3p2),  AllowStreamLocalForwarding
> defaults on. That means both local and remote unix socket port
> portforwarding are possible.
> 
> For Cygwin, it appears the remote form of this is not possible. The
> following message is seen on the client-side, regardless of whether
> sshd_config explicitly defines AllowStreamLocalForwarding "on", or
> "all":
> 
> |Forwarding port.
> |debug1: Remote: Server has disabled streamlocal forwarding.
> 
> Finding the code around this, and a three(?) component conditional
> expression that "fails" into that message, I discovered that the
> reason it is not allowed is the following conditional:
> 
> |		    (pw->pw_uid != 0 && !use_privsep)) {
> 
> and to my surprise, after compiling a debug version of sshd to discover
> this conditional, it turns out that use_privsep is set to zero (0).
> 
> I've been around the Cygwin community for many years, and I remember
> the time when ssh-host-config prompted for priv sep, and the creation
> of the "sshd" local user.
> 
> I remember the transition when that prompt was removed, and reading that
> priv sep was now "on permanently".
> 
> I think there is a misunderstanding here though, though I'm not 100%
> sure of my reading of the situation. It appears that though priv sep is
> on by default, for Cygwin, it is effectively off, as it cannot be
> implemented???

Privilege separation in OpenSSH consists of two independent parts, both
of which require AF_UNIX sockets.

The first part is transmission of peer credentials per the SO_PEERCRED
socket option.  This was relatively easy to implement.

The other part of privilege separation requires AF_UNIX sockets to allow
sending and receiving open file descriptors via the SCM_RIGHTS ancillary
data feature.  This does not work in Cygwin.

> DISABLE_FD_PASS is always set by autoconf for Cygwin. And my reading is
> that not having that capability effectively means whatever the other
> criteria, the executing process doesn't have sufficient "separation" of
> privilege to be treated in the same manner.

Yes, the parts of OpenSSH requiring descriptor passing are disabled in
OpenSSH.

> Otherwise, what's the solution?

Solution for what?  What is it you want to do?


Corinna

Re: sshd_config AllowStreamLocalForwarding perm off / effectively privsep off

[Shaddy Baddah]

Hi,

On 8/08/2023 3:40 am, Corinna Vinschen via Cygwin wrote:
> On Aug  7 22:11, Shaddy Baddah via Cygwin wrote:
..

> 
> Yes, the parts of OpenSSH requiring descriptor passing are disabled in
> OpenSSH.
> 
>> Otherwise, what's the solution?
> 
> Solution for what?  What is it you want to do?

Reverse unix socket forwarding. Like this:

|~aC
|ssh> -R /tmp/p2:/tmp/p1
|Forwarding port.
|debug1: Remote: Server has disabled streamlocal forwarding.

Despite configuration and documentation, this can never work on Cygwin.

And I was looking to what an agreeable patch for OpenSSH might be. But
if I have read the situation right, by policy, there cannot be one for
Cygwin.

I do have a workaround, but it's suboptimal.

-- 
Regards,
Shaddy

Re: sshd_config AllowStreamLocalForwarding *remote not possible* / effectively privsep off

[Shaddy Baddah]

Hi,

I've just updated the subject line for accuracy. Only remote/reverse
unix socket forwarding fails.

Further, I have a clarification that might have significance:

On 8/08/2023 3:40 am, Corinna Vinschen via Cygwin wrote:
 > On Aug  7 22:11, Shaddy Baddah via Cygwin wrote:
..
 >
 >> DISABLE_FD_PASS is always set by autoconf for Cygwin. And my reading is
 >> that not having that capability effectively means whatever the other
 >> criteria, the executing process doesn't have sufficient "separation" of
 >> privilege to be treated in the same manner.

Perhaps contrary to expectation, with the more conventional
remote/reverse TCP port forwarding, with Cygwin sshd, the LISTEN port
exists in the, is it called the monitor
(http://www.citi.umich.edu/u/provos/ssh/priv.jpg)/intermediatary sshd
process.

So something like:

|>~C
|ssh> -R 12345:22

will result in a (confirmed by netstat) LISTEN port in the SYSTEM owned
sshd process, which is the parent of the non-privileged owned sshd
process.

I'm not suggesting that this is not a considered situation, because to
my knowledge, it's a much different situation allowing an ssh user to
manipulate the filesystem (for unix sockets), as SYSTEM. Than using
netsocks as SYSTEM to try and bind TCP ports... I think???

But it certainly aligns with my newfound understanding of Cygwin's
"trade-off" form of privilege separation.

-- 
Regards,
Shaddy