This is the mail archive of the
mailing list for the Cygwin project.
RE: Possible Security Hole in SSHD w/ CYGWIN?
- From: "David Willis" <david_willis at comcast dot net>
- To: <cygwin at cygwin dot com>
- Date: Sat, 20 Feb 2016 11:53:46 -0800
- Subject: RE: Possible Security Hole in SSHD w/ CYGWIN?
- Authentication-results: sourceware.org; auth=none
- References: <CANnLRdhVrFcveO_jKb3_x=44WMJNO33DPnsJZ12Wus3U7Wo_fQ at mail dot gmail dot com> <019e01d163c2$d678c7e0$836a57a0$ at comcast dot net> <023901d165e4$925507d0$b6ff1770$ at comcast dot net> <87d1s1c8ld dot fsf at Rainer dot invalid> <CACoZoo3R4CDcgTMMex9QZ=Wh9a8CDvyUHpqj5+Br5xYFvGHvuQ at mail dot gmail dot com> <87a8n38t3r dot fsf at Rainer dot invalid> <CACoZoo3831x0PVOQ9j6zh+Q4EE4-LFNV7KQsgeyooPJmvM7qVA at mail dot gmail dot com> <20160215121101 dot GC7085 at calimero dot vinschen dot de> <003801d1693f$6a5d71a0$3f1854e0$ at comcast dot net> <20160217094335 dot GA5722 at calimero dot vinschen dot de> <20160218151257 dot GA14838 at calimero dot vinschen dot de>
- Reply-to: <cygwin at cygwin dot com>
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
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of
Sent: Thursday, February 18, 2016 7:13 AM
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
> 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.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple