public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "David Willis" <david_willis@comcast.net>
To: <cygwin@cygwin.com>
Subject: RE: Possible Security Hole in SSHD w/ CYGWIN?
Date: Sat, 20 Feb 2016 19:53:00 -0000	[thread overview]
Message-ID: <004801d16c18$699f7d90$3cde78b0$@comcast.net> (raw)
In-Reply-To: <20160218151257.GA14838@calimero.vinschen.de>

Hey, sorry I haven't had a chance to check in on this the last couple days

Thanks so much Corinna for implementing your idea in the new test release -
I haven't had a chance to test it yet but it sounds like it works as
expected. I really appreciate you taking the time to implement a fix for
this.

David

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Corinna Vinschen
Sent: Thursday, February 18, 2016 7:13 AM
To: cygwin@cygwin.com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

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


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  parent reply	other threads:[~2016-02-20 19:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-10  4:39 David Willis
2016-02-10  4:57 ` Stephen John Smoogen
2016-02-10  5:21   ` David Willis
2016-02-12 22:27     ` David Willis
2016-02-13  8:34       ` Achim Gratz
2016-02-13 21:15         ` David Willis
2016-02-14  0:34           ` Erik Soderquist
2016-02-14  1:29             ` David Willis
2016-02-14  1:48               ` Erik Soderquist
2016-02-14 10:49           ` Achim Gratz
2016-02-14  0:14         ` Erik Soderquist
2016-02-14  1:37           ` David Willis
2016-02-14 10:49           ` Achim Gratz
2016-02-14 18:36             ` Erik Soderquist
2016-02-15 12:11               ` Corinna Vinschen
2016-02-17  4:55                 ` David Willis
2016-02-17  9:43                   ` Corinna Vinschen
2016-02-18 15:13                     ` Corinna Vinschen
2016-02-18 17:10                       ` Erik Soderquist
2016-02-19 11:10                         ` Corinna Vinschen
2016-02-19 16:38                           ` Erik Soderquist
2016-02-20 19:53                       ` David Willis [this message]
2016-02-13  1:04     ` Erik Soderquist
2016-02-13 20:04       ` David Willis
  -- strict thread matches above, loose matches on Subject: below --
2016-02-09 15:56 David Willis
2016-02-09  6:43 David Willis
2016-02-09  7:53 ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004801d16c18$699f7d90$3cde78b0$@comcast.net' \
    --to=david_willis@comcast.net \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).