From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111729 invoked by alias); 12 Feb 2016 22:27:39 -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 111717 invoked by uid 89); 12 Feb 2016 22:27:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.9 required=5.0 tests=AWL,BAYES_50,CYGWIN_OWNER_BODY,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=CDs, SHOULD, credentials, Permission X-HELO: resqmta-po-05v.sys.comcast.net Received: from resqmta-po-05v.sys.comcast.net (HELO resqmta-po-05v.sys.comcast.net) (96.114.154.164) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 12 Feb 2016 22:27:37 +0000 Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-05v.sys.comcast.net with comcast id HaTK1s0024ueUHc01aTb5i; Fri, 12 Feb 2016 22:27:35 +0000 Received: from HOME1 ([24.18.54.164]) by resomta-po-03v.sys.comcast.net with comcast id HaTa1s00F3YafjL01aTbvu; Fri, 12 Feb 2016 22:27:35 +0000 Reply-To: From: "David Willis" To: References: <019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> In-Reply-To: <019e01d163c2$d678c7e0$836a57a0$@comcast.net> Subject: RE: Possible Security Hole in SSHD w/ CYGWIN? Date: Fri, 12 Feb 2016 22:27:00 -0000 Message-ID: <023901d165e4$925507d0$b6ff1770$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00179.txt.bz2 Anyone? 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. 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 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. 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]" 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. 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). Thanks, David -----Original Message----- From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of David Willis Sent: Tuesday, February 09, 2016 9:21 PM To: cygwin@cygwin.com Subject: RE: Possible Security Hole in SSHD w/ CYGWIN? Thank you for the response.. That is the problem though, it is not an error I am getting (that is in fact the issue is that I SHOULD be getting a "permission denied" but I am not). The problem is that I have access to things that I should not. Since this is plain text only I can't post a SS of the open session that is shown in Computer Management->Shared Folders->Sessions, but it shows the privileged server account "cyg_server" instead of the user that I am accessing the share as (the user I SSH'd in as). And I just found out with further testing that when I connect using a password to Cygwin SSHD server, then access the file share, I have the correct permissions and it shows an open session as the user I connected as like it should. So it is something specifically that happens when connecting using public key authentication. Here is an example though: [user]@[client machine] ~$ ssh [user]@[SSH server].[domain] Enter passphrase for key '/home/[user]/.ssh/id_dsa': Last login: Mon Feb 8 21:41:51 2016 from [client machine] [user]@[SSH server] //[file server]/[share] $ ls -l total 8 drwxrwx---+ 1 [admin user] Domain Users 0 Feb 7 18:29 [private folder] drwxrwx---+ 1 [user] Domain Users 0 Feb 7 17:31 [public folder] [user]@[SSH server] //[file server]/[share] $ ls -l [private folder] total 8 -rwxrwx---+ 1 [admin user] Domain Users 6070 Feb 6 22:50 [private file] Please note that the user on the client machine and the user I am connecting as on the SSH server are the same user account (a domain account). The [admin account] is a domain account w/ domain admin privileges. The private folder has NTFS ACLs set on it to prevent anyone other than domain admins from listing the contents (as does the file inside it have ACLs preventing anyone other than domain admins from reading it). The public folder is listable by any domain users. Now what happens when I login with a password instead of a key: [user]@[client machine] ~$ ssh [user]@[SSH server].[domain] [user]@[SSH server].[domain]'s password: Last login: Tue Feb 9 20:18:44 2016 from [client machine] [user]@[SSH server] //[file server]/[share] $ ls -l total 8 drwxr-x--- 1 Unknown+User Unknown+Group 0 Feb 7 18:29 [private folder] drwxrwx---+ 1 [user] Domain Users 0 Feb 7 17:31 [public folder] [user]@[SSH server] //[file server]/[share] $ ls -l [private folder] ls: cannot open directory [private folder]: Permission denied The behavior the second time is what I would expect the first time. Also in the second scenario, Computer Management->Shared Folders->Sessions shows the proper user being connected (the user I SSH'd in as) instead of the privileged server account "cyg_server". Thanks again for any help - much appreciated David -----Original Message----- From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Stephen John Smoogen Sent: Tuesday, February 09, 2016 8:57 PM To: cygwin@cygwin.com Subject: Re: Possible Security Hole in SSHD w/ CYGWIN? On 9 February 2016 at 21:39, David Willis wrote: > 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!!! > In general, you need to be able to cut and paste the errors you are seeing versus using words to describe them. There are several different things that what you are describing could look like so without that extra data it is hard to figure out how to duplicate what you might be seeing. -- Stephen J Smoogen. -- 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 -- 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 -- 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