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:reply-to:from:to:references:in-reply-to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=ABbgm2XmdD6RGmS6
	GEyVUYG0nmwvhcP0dq5GteUEcCUU1xTFucIURTdd0jiFME5X///VE7h4S+C5DUSa
	CAdv+D6IN4Py9F4wpEX9RdwfL7jDTgSaKZ9NfM+1U36pIcnKyw05myv6hWUVAmpT
	HtY5NQeI3MSVls7/vvwY8KyMOR0=
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:reply-to:from:to:references:in-reply-to
	:subject:date:message-id:mime-version:content-type
	:content-transfer-encoding; s=default; bh=g1xolGjyChGdp2M656OAd3
	HjJZw=; b=fWHFZk1bVJ/A+zA2LK2E63VLnLt6YnmsHPvduWo4SUO6lRta8Vai6M
	gatzGQVO7MxP5pKj7CaE0sCBw+qWS2FYxy4kgsVP30wjV/dIFJ6Sn17ukAqynmFx
	TYm9PSD/nqCsjXNqf5hIcijAKm+vBZ1MBSKIYsDXW6Zvc38oQ95T4=
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=4.3 required=5.0 tests=AWL,BAYES_40,CYGWIN_OWNER_BODY,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=H*i:sk:w AT mail., H*i:sk:ko0TZS1, H*f:AWr_1o, H*i:CACoZoo14
X-HELO:	resqmta-po-01v.sys.comcast.net
Reply-To:	<cygwin AT cygwin DOT com>
From:	"David Willis" <david_willis AT comcast DOT net>
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> <024901d166a3$a6930390$f3b90ab0$@comcast.net> <CACoZoo14+ko0TZS1NtAh8R6DknAF_aoWAb1r+Nx3H+AWr_1o+w AT mail DOT gmail DOT com>
In-Reply-To:	<CACoZoo14+ko0TZS1NtAh8R6DknAF_aoWAb1r+Nx3H+AWr_1o+w@mail.gmail.com>
Subject:	RE: Possible Security Hole in SSHD w/ CYGWIN?
Date:	Sat, 13 Feb 2016 17:29:25 -0800
Message-ID:	<025601d166c7$23eaa3c0$6bbfeb40$@comcast.net>
MIME-Version:	1.0
X-IsSubscribed:	yes

Hmm, storing the password in the registry would probably not be optimal... I
would probably rather deal with lack of network share access from SSH
sessions than store a plaintext password (haven't tested it so I can't say
for sure, but since I see no mention of encrypting or hashing the password
I'm guessing it is stored in plaintext)...

For authenticated access within a session, I would think it would be better
if the user was prompted to enter their password when attempting to access a
share, similar to what happens when attempting to access a share via Windows
Explorer (if you don't already have access with your currently logged on
credentials). I think based on everything I've found out this would be the
best solution to this scenario for SSH users that log in using key
authentication.

And to your second point, that is also what I would expect, is that if
anything there would be NO network access, rather than access based on the
account that the sshd process is running as, regardless of its access.
However what I gathered from Achim's message is that the access level of
cyg_server is precisely the reason the user would have network share access
with that account's privileges.

Thanks,

David

-----Original Message-----
From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of
Erik Soderquist
Sent: Saturday, February 13, 2016 4:34 PM
To: cygwin AT cygwin DOT com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

On Sat, Feb 13, 2016 at 4:15 PM, David Willis  wrote:
<snip>
> So you're telling me any user that logs in using key authentication 
> cannot access the network as the same user (i.e. this is the intended 
> behavior)? If that's the case wouldn't it be better not to allow 
> network access at ALL, rather than allowing it as the service account that
sshd is running as?

Responding to only this one piece at present

from https://cygwin.com/cygwin-ug-net/passwd.html

{{
-R, --reg-store-pwd      enter password to store it in the registry for
                           later usage by services to be able to switch
                           to this user context with network credentials.
}}
{{
Don't use this feature if you don't need network access within a remote
session.  You can delete your stored password by using `passwd -R' and
specifying an empty password.
}}

Since there are explicit instructions on how to store your Windows password
in a way that Cygwin sshd (and other Cygwin services) can use the password
for network authentication and that it says not to store the credentials if
you do not need network access when authenticating via public key, I would
make the logical assumptions that

#1: authenticated network access is supposed to be possible inside a public
key authenticated ssh session

#2: without storing the password as described, I should have no network
access at all, not the cyg_server account's network access (regardless of
how much or little access the cyg_server account has).

<snip>

-- Erik


--
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

- Raw text -