Re: Possible Security Hole in SSHD w/ CYGWIN?

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb 17 10:43, Corinna Vinschen wrote:
> 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.
> [bla, bla]
> > 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.

I implemented and tested the idea and it seems to work.  Note that the
underlying problem that we can't generate our own login session when using
method 1 persists.  However, the new code should avoid spilling cyg_server
credentials into the user session.

Please give the new Cygwin test release 2.5.0-0.4
(https://cygwin.com/ml/cygwin-announce/2016-02/msg00023.html) a try.


Thanks,
Corinna

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

Attachment: signature.asc
Description: PGP signature