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=Ab0KH/nj2WM+/nz+
	vqLphL114y8dUvfrNBxHKb92O6HVq3dicNQFQM6vaAJzHxCZshpn1SpxFSJRkVKw
	z1nnqeayzLnvMJrI+MaA+24h5R1liEU+lL1vBJmW//mZMBK8PQpgYyoCffi5gOea
	FleJSr3zjBUcoRoLifrWs2oFQiM=
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=0uOkrYOgmAlkO4BtFcildG
	hdcRo=; b=unl8DI0swXDfAI4WauVLKlhOszsdU2Hi1vglK18O4f5zTL+k7ru5Vv
	cDWebbQHkhUqowqI+etK0Ib6Mw8Jc1qVka3jA0H/Erbl6hjbhVEqkw+zw6qgGlbJ
	m1zqtOhl9uqmmJIkZOYirWDxm7y9eWa5UYlvAXXaSojay7+s6b8CM=
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=3.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=thru, navigate, cygwin-ug-net, cygwinugnet
X-HELO:	resqmta-po-12v.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:
In-Reply-To:
Subject:	RE: Possible Security Hole in SSHD w/ CYGWIN?
Date:	Tue, 9 Feb 2016 20:39:13 -0800
Message-ID:	<019c01d163bc$fe2fc500$fa8f4f00$@comcast.net>
MIME-Version:	1.0
X-IsSubscribed:	yes

Just to add an update to this, it appears that processes run from the shell
while logged into the CYGWIN SSHD server are run as the correct user - i.e.
I run a ping or cat a file and pipe it to less, and check Task Manager on
the SSHD server, and those processes show as being run as the user I SSH'd
in as, the way it should be.

So it looks like this bug is specifically when accessing files or directory
contents. I literally run a "ls -l" command from the local CYGWIN shell on
the SSHD server, against a file share that I have no access to, and get a
permission denied. I run the exact same command, SSH'd into that same box as
the same user against the same file share, and this time I can list the
directory contents. Same results with "cat"ing files in those directories.
What gives?

Any help on this VERY much appreciated!!!

Thanks,

David


-----Original Message-----
Sent: Tuesday, February 09, 2016 7:56 AM
To: 'cygwin AT cygwin DOT com'
Subject: RE: Possible Security Hole in SSHD w/ CYGWIN?

Sorry for starting a new thread w/ the reply, forgot to subscribe before
posting my question yesterday...

Thanks for getting back so quickly

Yes, I have read that page pretty much from top to bottom, and as far as I
know I have configured sshd and the user accounts correctly. I have a
non-privileged, disabled account named "sshd", as well as a privileged
account called "cyg_server". Privilege separation seems to be working fine -
i.e. when the request for a connection comes in the process is running as
"sshd", then it spawns a privileged process running as "cyg_server" once the
user is authenticated.

However no I am not logging in with a password; I have setup public key
authentication.

And the user I'm being connected as (as seen from the file share server) is
not the "sshd" user account, it is the privileged "cyg_server" user account.
Although that account has no rights to logon interactively or thru Terminal
Services, it is a privileged account on the file server (because the file
server is also running CYGWIN and thus must allow privileged rights to that
account as well). I should clarify that in my case, cyg_server is a domain
account (not a local account).

And the way I can verify, is that I have a folder on that share that the
user I am authenicating as does not have rights do view, but cyg_server does
(because Administrators on that server do), and when I connect as my user
via SSHD to any one of my other machines on the domain running CYGWIN, I can
then navigate to and read the contents of that file share when I shouldn't
be able to. If I try to do the same thing, from the same account, but on my
machine locally without connecting to any other CYGWIN SSH server, I get a
"Permission denied", which is what I would expect.

Thank you for your help on this.

David

----------------------------------------------------------------------------
--------------------------

Did you read https://cygwin.com/cygwin-ug-net/ntsec.html, configured sshd
and the user accounts correctly and are logging in with a password using
either of the methods described?

FWIW, I'm seeing the connected user as the one that I logged into via ssh. 
In fact the sshd user account doesn't have any network access rights anyway,
so I couldn't connect to any network share if that acount would be used.


Regards,
Achim.

-----Original Message-----
Sent: Monday, February 08, 2016 10:43 PM
To: 'cygwin AT cygwin DOT com'
Subject: Possible Security Hole in SSHD w/ CYGWIN?

Hello,

I noticed that when connecting via SSH to a CYGWIN-based SSHD server, if the
user connects to a network share (i.e. they CD to the share UNC path in the
BASH/CYGWIN shell), they get connected as the privileged server user account
created for privilege separation when SSHD is configured w/ ssh-host-config.
In other words, they have the rights of that account, and if that account
happens to be a domain admin (or even a local admin on the box hosting the
share), that user has full admin rights on that share, when in fact they
should have the rights assigned to the user account they SSH'd in with.

To reproduce, connect via SSH (from either a Linux or CYGWIN/Windows client)
to a CYGWIN-based SSHD server using a normal privileged user account (an
account preferably that is not an admin either on the client or server
machine). Once connected to the Windows SSHD server, CD to a UNC path of a
network share. Once CD'd to that path, check Computer Management on that
server, and go to Shares->Open Sessions, and you will see that the user
connected is the privileged SSHD server account (and it will obviously show
as being connected from the machine you are SSH'd into).

Anyone else ever notice this before?

Running OpenSSH v7 BTW, SSH client is Win7, SSH server Win7, file share
server Win2008R2


Thanks,


David



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