This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Possible Security Hole in SSHD w/ CYGWIN?


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

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



-----Original Message-----
From: [] On Behalf Of
David Willis
Sent: Tuesday, February 09, 2016 9:21 PM
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
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


-----Original Message-----
From: [] On Behalf Of
Stephen John Smoogen
Sent: Tuesday, February 09, 2016 8:57 PM
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:
Unsubscribe info:

Problem reports:
Unsubscribe info:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]