X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=KzeSeNPqCit00AOvCN0t0ybKBtbtQU4180NtD1eUxFJUnArtRL7wH
	yrwFQYO8KYkfXa7pI+8T1wDZA6tzfIvnzTMzoLznMyXheUXmK8dVxvAuhwaa4Wl3
	u4ruDPV3T4+Qz4MWFcaFPZrfm8fbBgvSxLkxUEG7S4qrPPDReFHX1M=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=HK73JKbsSDTgFqj32oHDHLvszgg=; b=xfliq9RBlFzEmz4QmWd86M7+ZRD2
	dabGwtQCvXPdcJm5Gd9CdTZzYyTJdeuPZvFpaOQYPMjs68oEITriBV0cKRz0shwu
	yaD0tlrDJkrvYfxLE8uGAbePP5ALgk7SZsRqG2p7VMA8paaA+mfhVcg5D7GXrpY1
	qXwxeoztjCbDQAA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-93.9 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=interpretation, offbase, unintended, wellversed
X-HELO:	calimero.vinschen.de
Date:	Wed, 17 Feb 2016 10:43:35 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Possible Security Hole in SSHD w/ CYGWIN?
Message-ID:	<20160217094335.GA5722@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <CANnLRdhVrFcveO_jKb3_x=44WMJNO33DPnsJZ12Wus3U7Wo_fQ AT mail DOT gmail DOT com> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.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$@comcast.net>
MIME-Version:	1.0
In-Reply-To:	<003801d1693f$6a5d71a0$3f1854e0$@comcast.net>
User-Agent:	Mutt/1.5.24 (2015-08-30)

--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 o=
uts
> 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) meani=
ng
> the token used when accessing a share will stay as the token of the calle=
r -
> 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

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

--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWxEDHAAoJEPU2Bp2uRE+gNzMQAKXaLUg8RPwgKST+yJ+3UqW9
/8xLGxYCNLaeBHPM73XXe8enphF0dZWYZ87HjSkEumzxhy0STtPndyv3jtHhvNX6
PoqMjpHrMXy15/aK3sFGa0cwrRxsZt7zkriMin+WVHTI+CkL5BFemtj8b35oO0p6
rg1jpA2DROaAuyt6Zz90+FjDAcvHCF99dvqRlGWo8kQIo5iKwjXakU+SuoB3J7aF
06HBDfhzyn6oB6Zb0fD/WOvvxuZkHqzV/npkfdzrSDDuvxGACeOC9I3qeh7zOfkK
t4sPzjVmz+C9oZEneqbmTr17HR4fQarpiBt1Ukin2Izw/9jaLD/N7zJWANgdCaKr
QspmpO3hyCNQeaL5jwAHhUTcPfOb1vl7j5hh7BjIuao9YyUP9P1ayoutlykJgKVy
Sn9KIbRlKkX8z4B8PzJsxraPTc0Nd40pCaP3G3zNXQQV/pKeXO90Uqu8PEtYS3wn
icXEmAwLyTUW5UrcNZ5+XStqHKlDU034OALomTFjHJ/iSfgv/LbLehsd2L8RdeRt
4nAMunwknsAKcqVgPGXC2CjqWLVIoGE0bRft3SCzEKjZNiCcWaL/9MjEOT+Lmr+d
hvkaaowmTThsfo6ZkOoUiJJ7Yjz8wu8psi+ZezZZJBFSo9M0LTSHh/8Zx07c/GEv
mQbSQwMfmzI2O3ERj1al
=hrLD
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--

- Raw text -