From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127144 invoked by alias); 10 Feb 2016 04:39:18 -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 127134 invoked by uid 89); 10 Feb 2016 04:39:17 -0000 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 Received: from resqmta-po-12v.sys.comcast.net (HELO resqmta-po-12v.sys.comcast.net) (96.114.154.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 10 Feb 2016 04:39:15 +0000 Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-12v.sys.comcast.net with comcast id GUf51s00154zqzk01UfEZx; Wed, 10 Feb 2016 04:39:14 +0000 Received: from HOME1 ([24.18.54.164]) by resomta-po-11v.sys.comcast.net with comcast id GUfD1s00H3YafjL01UfDjE; Wed, 10 Feb 2016 04:39:14 +0000 Reply-To: From: "David Willis" To: References: In-Reply-To: Subject: RE: Possible Security Hole in SSHD w/ CYGWIN? Date: Wed, 10 Feb 2016 04:39:00 -0000 Message-ID: <019c01d163bc$fe2fc500$fa8f4f00$@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/msg00129.txt.bz2 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@cygwin.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@cygwin.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