From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127203 invoked by alias); 17 Feb 2016 09:43:40 -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 127184 invoked by uid 89); 17 Feb 2016 09:43:39 -0000 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 Received: from ipbcc0d020.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Feb 2016 09:43:38 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id F3DE4A805A7; Wed, 17 Feb 2016 10:43:35 +0100 (CET) Date: Wed, 17 Feb 2016 09:43:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Possible Security Hole in SSHD w/ CYGWIN? Message-ID: <20160217094335.GA5722@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <003801d1693f$6a5d71a0$3f1854e0$@comcast.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-02/txt/msg00265.txt.bz2 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3300 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" Content-length: 819 -----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--