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:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; q=dns; s=default; b=nkX4R
	uJLz6dvNdjjUqWfj02wcoc4IpeDEzjpYVO7x9Krs0uANmeS5oe5hb3+OeumS0Sdn
	lDrCXS4gGKa2O6yi/KU1WT3lA0NkhWXOmRuEXF9B8Y1otqiAgC8kKhdpfqhTE9pc
	42FZbRb6Q+3o1UMslVDRyS2Anl7roWn6DCdKOo=
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:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; s=default; bh=jmPiz6fiUmZ
	y+NXSd3xTg2DMQTY=; b=v5P8z3LOozVm5UvIwVvgS+kSHmyuMfBDeVQqMbfEPwB
	3CoMQV5RK57C9gZpK/9r12seDEwCgN2p6m9noztQb+Z4X9o303/G2LIxCY+kNi1W
	ppRnuMIT/tz0HSDhMJT4fb1ib064y+oOMRM4Dnpndj5Uyx5UYUBHTJDl7gDlS4zo
	=
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=-1.0 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=CDs, authenticate, credentials, editrights
X-HELO:	mail-in-16.arcor-online.net
X-DKIM:	Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net 3q2Q331GZqz7lv5
From:	Achim Gratz <Stromeko AT nexgo DOT de>
To:	cygwin AT cygwin DOT com
Subject:	Re: Possible Security Hole in SSHD w/ CYGWIN?
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>
Date:	Sat, 13 Feb 2016 09:34:06 +0100
In-Reply-To:	<023901d165e4$925507d0$b6ff1770$@comcast.net> (David Willis's message of "Fri, 12 Feb 2016 14:27:34 -0800")
Message-ID:	<87d1s1c8ld.fsf@Rainer.invalid>
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux)
MIME-Version:	1.0

David Willis writes:
> I know this is a somewhat unique and I guess obscure issue, but if someone
> could please look into this - I would be very surprised if it was NOT
> reproducible following the steps below. Because if this is actually the case
> it is in fact granting permissions that it should not be granting to SSH
> users that log in using public keys.

You still do not seem to have understood what

https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview

is trying to tell you.  The windows box you log into _must_ have a
password for the user that logs into via SSH using one of the methods
listed there in order for the user credentials to become valid on the
network.

> Like I said, there is no error message or anything (due to the nature of the
> issue) but the steps to reproduce are as follows:
>
> Cyg_server is the privileged account used by CYGWIN for SSH privilege
> separation, and is a DOMAIN account, and a member of DOMAIN ADMINS

Just why do you think that cyg_server should be a domain admin?  It only
needs local admin membership plus some capabilities that allow it to
create a new user token.  Does it have those capabilities at all,
i.e. what does

editrights -lu cyg_server

produce as output?  If it doesn't have them, then it can't actually
switch the user, password or not.

> User on the domain (a regular-privileged domain user) logs into another box
> on the domain using public key method (NOT password). He logs in as himself,
> which has regular non-admin privileges on both the client and server
> boxes.

Unless that account can authenticate fully on that box (i.e. there's a
password), it doesn't have network access.

> The client box is either Linux or Windows w/ CYGWIN, but the SSH server must
> be CYGWIN.
>
> After connecting to the CYGWIN SSH server, the user CD's to a Windows server
> file share's UNC path - i.e. "cd //[SERVER]/[share]"

This would fail if you've not set up cyg_server as a domain admin, if
you've even got that far.  In fact you'd not be able to use any shares
that require authentication.

> Now you check Computer Management on the file server, check Shared
> Folders->Sessions, and you see that instead of the user having an open
> session, the cyg_server user has an open session (from the machine that you
> SSH'd to).
>
> The user now has access to anything that cyg_server would have access to.
> Since cyg_server is a domain admin, that would be pretty much everything
> aside from shares that are specifically locked down to certain users and not
> allowing admins.

Don't make cyg_server a domain admin, then.

> I don't know if this bug is with SSH or CYGWIN, but it only occurs on CYGWIN
> SSH servers (not Linux SSH servers, although its hard to test because when
> SSH'd into a Linux box I can't CD directly to a UNC path, I have to mount
> the share instead, and specify user credentials to do so).

I don't know how you've arrived at the setup you just described, but
it's not the one that sshd_host_config produces.  Yes, setting up an
SSHD wrongly can open up security holes, no surprise here.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

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