Re: Possible Security Hole in SSHD w/ CYGWIN?

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]

On Feb 16 20:55, David Willis wrote:
> First let me say that I'm not too well-versed in coding and the ins and outs
> of how processes utilize credentials when they are spawned. However, the
> jist of it seems to be that if there are no credentials saved with passwd -R
> to replace the current user token with that of the user that is SSH'd in,
> then there is no way to change that token at all (or get rid of it) meaning
> the token used when accessing a share will stay as the token of the caller -
> namely cyg_server? Please correct me if I'm way off-base but that seems to
> be my interpretation of this.

It's wrong, but it's not easy to grok how this all works under the hood.
First of all, refering to
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview, only
method 1 should be affected.

There are two concepts at work here, one is the user token attached to
each process and defining group membership, permissions and privileges
of a process, the other one is the logon session in which the processes
are running.

The process started by sshd is running with a user token which belongs
to the user the process is supposed to run with.  The group memberships,
the permissions and privileges are set as desired.

However, the network credential are apparently not stored in the user token,
but are connected to the logon session.  And here comes the difference
between method 1 and the other two methods:

- In method 1, Cygwin creates a user token from scratch.  This occurs
  inside the Cygwin DLL itself and so in normal user space.  In Windows,
  there's no way to create a new logon session outside of the LSA.  And
  given that we don't have any credentials to authenticate the new user
  account (remember: we're trying to switch the user context without
  having to specify a password) we have no choice other than to run the
  new processes using the new user token under the logon session of the
  current user.  That's "cyg_server" usually.  Thus, the process has a
  user token for the correct user, but shares the logon session with the
  cyg_server process.

- When using method 2, the Cygwin DLL calls into the Cygwin authentication
  package which is running inside the LSA.  Therefore the authentication
  package can request a new logion session and attach it to the user token
  created inside the LSA.  So the new process is running in it's own
  logon session and thus not sharing the logon session with cyg_server.

- When using method 3, the token is created using the LogonUser function
  which calls into the LSA by itself.  The new user token is running in
  its own logon session.

> If that is the case, it seems this is an unintended side effect of the way
> CYGWIN and sshd work together, and with the current state of Windows there
> isn't really a way around it.

There might be a way around that.  I have a vague idea what to do to
create a new logon session, even when creating the token from scratch
per method 1, which would not share the network credentials of the
caller.  But it's just that yet, an idea.

If anybody has an idea how to perform this action, please share!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]