From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75851 invoked by alias); 20 Feb 2016 19:53:53 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 75842 invoked by uid 89); 20 Feb 2016 19:53:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.2 required=5.0 tests=AWL,BAYES_20,CYGWIN_OWNER_BODY,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=bla, refering, Hx-languages-length:2440, H*UA:Outlook X-HELO: resqmta-ch2-08v.sys.comcast.net Received: from resqmta-ch2-08v.sys.comcast.net (HELO resqmta-ch2-08v.sys.comcast.net) (69.252.207.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 20 Feb 2016 19:53:50 +0000 Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-08v.sys.comcast.net with comcast id Ljtn1s0042D5gil01jtnTN; Sat, 20 Feb 2016 19:53:47 +0000 Received: from HOME1 ([24.18.54.164]) by resomta-ch2-06v.sys.comcast.net with comcast id Ljtm1s00d3YafjL01jtnSV; Sat, 20 Feb 2016 19:53:47 +0000 Reply-To: From: "David Willis" To: References: <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.net> <87d1s1c8ld.fsf@Rainer.invalid> <87a8n38t3r.fsf@Rainer.invalid> <20160215121101.GC7085@calimero.vinschen.de> <003801d1693f$6a5d71a0$3f1854e0$@comcast.net> <20160217094335.GA5722@calimero.vinschen.de> <20160218151257.GA14838@calimero.vinschen.de> In-Reply-To: <20160218151257.GA14838@calimero.vinschen.de> Subject: RE: Possible Security Hole in SSHD w/ CYGWIN? Date: Sat, 20 Feb 2016 19:53:00 -0000 Message-ID: <004801d16c18$699f7d90$3cde78b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00317.txt.bz2 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