RE: Possible Security Hole in SSHD w/ CYGWIN?

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Stephen John Smoogen]

On 9 February 2016 at 21:39, David Willis <david_willis@comcast.net> 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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

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 <david_willis@comcast.net> 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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

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 <david_willis@comcast.net> 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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist]

On Wed, Feb 10, 2016 at 12:21 AM, David Willis wrote:
> 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

With the precise steps listed/demonstrated, I've reproduced it

I connected with ssh as a normal user using a private key, and cd'd to
//server/c$/ successfully, and in the Windows active sessions, it does
indeed show "cyg_server" as the connected user, not the user I logged
in with.  Trying this using a password rather than a private key
behaves as expected.

Taking this a step further, I created a new directory from Windows
Explorer and reset the permissions to explicitly deny access to the
normal user I tested with.  Then I tried to cd to
/cygdrive/c/access_denied_test/ and received the expected access
denied message, but when I tried to cd to
//server/c$/access_denied_test/ I succeeded, and was able to create
new files in the directory.

I can provide screen shots of the reproduction without the need to
redact quite so much.

-- Erik

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Achim Gratz]

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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

Thanks for taking the time to reproduce this - so now I know its not just me :) And to your point about connecting with a local path vs. a network path, I noticed that too - permissions are correct when accessing anything locally, but when accessing via a network path (even if it is to your own machine), will reproduce this issue.

Can any developers weigh in as to where the core of the problem might lie and/or how it would possibly be fixed?

Thanks,

David

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Erik Soderquist
Sent: Friday, February 12, 2016 5:04 PM
To: cygwin@cygwin.com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

With the precise steps listed/demonstrated, I've reproduced it

I connected with ssh as a normal user using a private key, and cd'd to
//server/c$/ successfully, and in the Windows active sessions, it does
indeed show "cyg_server" as the connected user, not the user I logged
in with.  Trying this using a password rather than a private key
behaves as expected.

Taking this a step further, I created a new directory from Windows
Explorer and reset the permissions to explicitly deny access to the
normal user I tested with.  Then I tried to cd to
/cygdrive/c/access_denied_test/ and received the expected access
denied message, but when I tried to cd to
//server/c$/access_denied_test/ I succeeded, and was able to create
new files in the directory.

I can provide screen shots of the reproduction without the need to
redact quite so much.

-- Erik



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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

First of all, it is one thing to ask me why I have set this up the way I did
- its another to tell me I've set it up "wrong", especially without known
the ins and outs of my domain and network.
 
> 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.

So you're telling me any user that logs in using key authentication cannot
access the network as the same user (i.e. this is the intended behavior)? If
that's the case wouldn't it be better not to allow network access at ALL,
rather than allowing it as the service account that sshd is running as?

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

Yes it has those capabilities. I don't "think" it "needs" to be a domain
admin - yes there are other solutions such as making it a local admin
individually on each box running sshd, but currently I don't have a GPO
setup to do that, and doing it individually on each machine that runs sshd
is impractical. I am looking to implement a GPO that does just that at some
point in the near future but this is the way it is setup currently  in order
to give it local admin rights on all boxes. Like I said, I agree there are
better ways of going about this and I'm not saying the current
implementation is best practice but this is what I've got to work with
currently.

And yes I know about the other rights it needs - Act as a part of the OS,
Create a token object, Log on as a service and Replace a process-level
token. There are GPOs in place to give it those rights based on the groups
it is in.

There are also GPOs in place to prevent it from logging in interactively or
through terminal services - the ONLY logon method right it has is to logon
as a service. This is BECAUSE of the fact that it is a domain admin account,
to mitigate the access it has on the domain.

> Unless that account can authenticate fully on that box (i.e. there's a
> password), it doesn't have network access.
> 
> 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.

Again, so this is intended behavior when logging in with keys? And
furthermore you are saying the only reason that I have network access as the
cyg_server account is because it is a domain admin, and if it was not, there
would be no network access whatsoever?

So if I am hearing this right, anyone using SSH with key authentication
instead of password authentication, has NO network access through SSH
sessions at all? That seems unlikely, but if that's the case then so be it.

> Don't make cyg_server a domain admin, then.

Again, that is the current setup that I have to work with. And again, yes I
plan to implement a GPO to instead grant it local admin rights on each box
so that it does not need to be a domain admin to have those rights, but that
is not in place yet. Not arguing about what is best practice here, just
trying to get to the bottom of why this issue is occurring.

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

Yes you're right, it is not the one that ssh_host_config produces.
Ssh_host_config would create a SEPARATE local admin account on EVERY box its
run on. That is impractical to manage on a domain and not the setup I want.

Hopefully now you understand a little more why I've arrived at the setup I
have. I need a setup that is manageable at the domain level - I do not have
the time or resources to manage local accounts each box running sshd
individually, grant them each their own individual rights, etc. I know
cyg_server needs LOCAL admin rights - the old way of implementing this was
to use a domain account so that we don't have separate local accounts on
each box, and make it a domain admin to grant it admin rights on all servers
and workstations. I fully understand that this is not a best practice, and
like I said, there is a GPO setting that will allow local admin rights on
all boxes to a domain user w/o making them a domain admin, and this is
exactly what I plan to implement in the near future. However it is not
implemented currently, so this is the situation I am facing right now.

If you are saying without domain admin rights there would be no network
access at all granted, well, I guess that's a solution.

I prefer to keep password authentication DISABLED for security reasons
(which is highly recommended by numerous guides, including the Cygwin site
itself if I remember correctly). If however key authentication means no
access to network shares whatsoever (assuming the service account is not a
domain admin), that seems to make things difficult.

As a closing note, I've been polite here asking for help, pointing out a
possible issue. It would have been very easy to say something like "normally
no network access is allowed when logging in w/ key authentication, and
making cyg_server a domain admin is the only reason this issue is occurring,
and it is not a recommended best practice" and I would say OK thank you very
much I understand that and it makes sense. Instead of going to great lengths
to tell me how "wrong" my setup is and implying that I know nothing about
what I'm doing.

You do not understand why people have things setup the way they do and there
may be reasons behind it. So I would not be so quick to say that people have
things setup "wrong" - you could just say "if you go with that setup, this
will be an unintended side effect".

I can assure you I do understand the rights that cyg_server needs to
function, why cyg_server was made a domain admin and why I do not "go with
the default setup that ssh-host-config" provides". The one thing I did not
understand was that authenticating with a key was NOT equivalent to
authenticating with a password. I now understand that fact - I would now
suggest that in the documentation you explicitly point out that when logging
in w/ key auth, you have the rights on the network that cyg_server has. I
don't think that point is explicitly made in the documentation, and I don't
think it would be a bad idea to do so.

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist]

On Sat, Feb 13, 2016 at 3:34 AM, Achim Gratz wrote:
> 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.

You are making unwarranted and rather rude assumptions here; that
doesn't help anyone.

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

I would suspect Domain Admin for the Cyg_server account is a
requirement of David's environment, which neither of us know anything
about at present.  I know I've had to do things that were not "best
practice" due to corporate policy on more occasions than I care to
count.

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

$ editrights -lu cyg_server
SeAssignPrimaryTokenPrivilege
SeCreateTokenPrivilege
SeTcbPrivilege
SeServiceLogonRight
SeDenyRemoteInteractiveLogonRight

These are the results on my host where I was able to reproduce the
issue locally.

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

Having a password and using that password for ssh are two very
different things.  In fact, in an earlier message, he explicitly
stated that the user does have a password, and when logging using the
password rather than the public key, he receives the expected access
denied message since the user account does not have access to the
share.  It is only when logging into ssh via public key does he
experience the issue described.

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

Actually the Cygwin doc does include instructions for accessing
network shares when using ssh public key 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.

Again you are making assumptions about the environment David is
required to use; Domain Admin may not be optional for his environment.
Yes, I have had instances where all local accounts were killed off due
to corporate policy, so the only way to have local admin at all was
via a Domain Admin account.  (The person who wrote that policy and I
argued very heatedly over it, but ultimately, it was not my decision).

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

Once again, assumptions.  While I can't explicitly vouch for David's
environment, as I do not have access to check, I can vouch for mine,
and mine was configured using sshd_host_config, with the only changes
after sshd_host_config being regarding TCP and X tunneling.

--- Erik

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist]

On Sat, Feb 13, 2016 at 4:15 PM, David Willis  wrote:
<snip>
> So you're telling me any user that logs in using key authentication cannot
> access the network as the same user (i.e. this is the intended behavior)? If
> that's the case wouldn't it be better not to allow network access at ALL,
> rather than allowing it as the service account that sshd is running as?

Responding to only this one piece at present

from https://cygwin.com/cygwin-ug-net/passwd.html

{{
-R, --reg-store-pwd      enter password to store it in the registry for
                           later usage by services to be able to switch
                           to this user context with network credentials.
}}
{{
Don't use this feature if you don't need network access within a remote
session.  You can delete your stored password by using `passwd -R' and
specifying an empty password.
}}

Since there are explicit instructions on how to store your Windows
password in a way that Cygwin sshd (and other Cygwin services) can use
the password for network authentication and that it says not to store
the credentials if you do not need network access when authenticating
via public key, I would make the logical assumptions that

#1: authenticated network access is supposed to be possible inside a
public key authenticated ssh session

#2: without storing the password as described, I should have no
network access at all, not the cyg_server account's network access
(regardless of how much or little access the cyg_server account has).

<snip>

-- Erik

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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

Hmm, storing the password in the registry would probably not be optimal... I
would probably rather deal with lack of network share access from SSH
sessions than store a plaintext password (haven't tested it so I can't say
for sure, but since I see no mention of encrypting or hashing the password
I'm guessing it is stored in plaintext)...

For authenticated access within a session, I would think it would be better
if the user was prompted to enter their password when attempting to access a
share, similar to what happens when attempting to access a share via Windows
Explorer (if you don't already have access with your currently logged on
credentials). I think based on everything I've found out this would be the
best solution to this scenario for SSH users that log in using key
authentication.

And to your second point, that is also what I would expect, is that if
anything there would be NO network access, rather than access based on the
account that the sshd process is running as, regardless of its access.
However what I gathered from Achim's message is that the access level of
cyg_server is precisely the reason the user would have network share access
with that account's privileges.

Thanks,

David

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Erik Soderquist
Sent: Saturday, February 13, 2016 4:34 PM
To: cygwin@cygwin.com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

On Sat, Feb 13, 2016 at 4:15 PM, David Willis  wrote:
<snip>
> So you're telling me any user that logs in using key authentication 
> cannot access the network as the same user (i.e. this is the intended 
> behavior)? If that's the case wouldn't it be better not to allow 
> network access at ALL, rather than allowing it as the service account that
sshd is running as?

Responding to only this one piece at present

from https://cygwin.com/cygwin-ug-net/passwd.html

{{
-R, --reg-store-pwd      enter password to store it in the registry for
                           later usage by services to be able to switch
                           to this user context with network credentials.
}}
{{
Don't use this feature if you don't need network access within a remote
session.  You can delete your stored password by using `passwd -R' and
specifying an empty password.
}}

Since there are explicit instructions on how to store your Windows password
in a way that Cygwin sshd (and other Cygwin services) can use the password
for network authentication and that it says not to store the credentials if
you do not need network access when authenticating via public key, I would
make the logical assumptions that

#1: authenticated network access is supposed to be possible inside a public
key authenticated ssh session

#2: without storing the password as described, I should have no network
access at all, not the cyg_server account's network access (regardless of
how much or little access the cyg_server account has).

<snip>

-- Erik


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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

Also, just wanted to respond to this one piece of the message to clarify -
The only change I made to what ssh_host_config does is to use the existing
domain admin account cyg_server rather than creating a new local admin
account (and it actually detects it automatically if it exists already so
this isn't even really doing anything different)

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Erik Soderquist
Sent: Saturday, February 13, 2016 4:14 PM
To: cygwin@cygwin.com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

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

Once again, assumptions.  While I can't explicitly vouch for David's
environment, as I do not have access to check, I can vouch for mine, and
mine was configured using sshd_host_config, with the only changes after
sshd_host_config being regarding TCP and X tunneling.

--- Erik



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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist]

On Sat, Feb 13, 2016 at 8:29 PM, David Willis wrote:
> Hmm, storing the password in the registry would probably not be optimal... I
> would probably rather deal with lack of network share access from SSH
> sessions than store a plaintext password (haven't tested it so I can't say
> for sure, but since I see no mention of encrypting or hashing the password
> I'm guessing it is stored in plaintext)...

It is encrypted, but since cygwin needs to be able to use that
password to authenticate against Windows processes for the network
authentication, it is a reversible encryption, so it would be
relatively easy for a determined attacker to code their own reversal
of the encryption.  The full doc calls it obfuscation to avoid
confusion with the usual one way encryption done on passwords.  I have
not looked at where in the registry it is stored or what the
permissions on those keys are, but I would assume local admin
privilege is required to access it since the doc also states users
can't save the password if the cygwin processes are not running and
cyg_server requires local admin; logical extension, since the process
already requires local admin, make local admin required to read the
encrypted saved passwords.  (Again, this is my assumption; I have not
looked it up).

> For authenticated access within a session, I would think it would be better
> if the user was prompted to enter their password when attempting to access a
> share, similar to what happens when attempting to access a share via Windows
> Explorer (if you don't already have access with your currently logged on
> credentials). I think based on everything I've found out this would be the
> best solution to this scenario for SSH users that log in using key
> authentication.

"best", possibly, though may or may not be feasible, and "best" is
often very subjective.  Also would reduce the "Linux look and feel"
that is one of the goals on cygwin.

> And to your second point, that is also what I would expect, is that if
> anything there would be NO network access, rather than access based on the
> account that the sshd process is running as, regardless of its access.
> However what I gathered from Achim's message is that the access level of
> cyg_server is precisely the reason the user would have network share access
> with that account's privileges.

Yes... I was very surprised to say the least that I could access the
c$ admin share with a non-admin account... that opens things like
replacing core OS files very easily to anyone who authenticates with a
public key.

-- Erik

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Achim Gratz]

David Willis writes:
> So you're telling me any user that logs in using key authentication cannot
> access the network as the same user (i.e. this is the intended behavior)? If
> that's the case wouldn't it be better not to allow network access at ALL,
> rather than allowing it as the service account that sshd is running as?

You don't have access to anything beyond the machine you've logged into
associated with that user account until you create a new logon session
for that account on that machine and you need to have the password for
this token to be created.  The same thing happens if you leave a remote
desktop session lingering for a day or so, you will then have to give
your password anew since those tokens or rather the Kerberos tickets
based on them will expire.  If you don't do that, you are still logged
into the machine in question and can do pretty much anything there as
you are used to, but you are no longer authenticated for network access.

> Again, so this is intended behavior when logging in with keys? And
> furthermore you are saying the only reason that I have network access as the
> cyg_server account is because it is a domain admin, and if it was not, there
> would be no network access whatsoever?

You could access whatever anybody could access who is authenticated
locally or a machine that has joined the domain; that shouldn't be much.
But anything requiring more specific access rights associated with your
user account would be denied because you're not fully authenticated.

> So if I am hearing this right, anyone using SSH with key authentication
> instead of password authentication, has NO network access through SSH
> sessions at all? That seems unlikely, but if that's the case then so be it.

Either that (assuming that you can't use a share that everyone has
access to, which is unlikely) or you'd use the "passwd -R" dance, which
is iffy in it's own right and certainly not something that you should
roll out to just about any machine.  Plus all the users have to remember
that each time they're changing their passwords they also need to do the
"passwd -R" again on each machine they ssh into lest they lock
themselves out pretty quickly.

Another option is to use password authentication on the first login to
each server, then start another sshd as that user from the session just
established and then use that secondary sshd with public key login.  The
secondary sshd would probably have to be restarted after a certain time
when the Kerberos tickets expire.

> Yes you're right, it is not the one that ssh_host_config produces.
> Ssh_host_config would create a SEPARATE local admin account on EVERY box its
> run on. That is impractical to manage on a domain and not the setup I want.

What you want to do can (and should) be done without giving cyg_server
domain admin rights.  It needs to be restricted as much as possible,
given that it already has some very powerful capabilities.  You haven't
described the rest of the setup process for sshd on each box, so I won't
comment on the practicality of using local accounts anyway.  I am quite
happy with using a local account since it allows me to give each
cyg_server a completely random password that works on just that machine
and nowhere else and doesn't need to be recorded anywhere after the
services have been installed.

> I can assure you I do understand the rights that cyg_server needs to
> function, why cyg_server was made a domain admin and why I do not "go with
> the default setup that ssh-host-config" provides".

However stingy you felt my remark about your application of the domain
admin right was, I keep insisting that you shouldn't use it in that way,
even if it seems to do what you want.  It also does lots of things you
absolutely don't want.  In fact, there should be no permanently active
accounts with domain admin rights anywhere on your network if you care
about security.

https://technet.microsoft.com/en-us/library/dn487454.aspx
https://www.beyondtrust.com/blog/best-practices-for-managing-domain-admin-accounts/

> The one thing I did not
> understand was that authenticating with a key was NOT equivalent to
> authenticating with a password.

That's the whole point of

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

although it may seem somewhat long-winded.  If you think that the
documentation can be improved, I'm sure Corinna doesn't mind getting a
patch.

> I now understand that fact - I would now
> suggest that in the documentation you explicitly point out that when logging
> in w/ key auth, you have the rights on the network that cyg_server has. I
> don't think that point is explicitly made in the documentation, and I don't
> think it would be a bad idea to do so.

That may actually be an unintended consequence of how Windows deals with
the Kerberos tickets that govern network access and should be considered
a bug.  I'm not sure if or how that can be avoided, but it would be nice
if sshd did not present those tickets at all.  But there wouldn't have
been a valid ticket to present if you hadn't made cyg_server a domain
admin.


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Achim Gratz]

Erik Soderquist writes:
> I would suspect Domain Admin for the Cyg_server account is a
> requirement of David's environment, which neither of us know anything
> about at present.  I know I've had to do things that were not "best
> practice" due to corporate policy on more occasions than I care to
> count.

If that's the case, then security of the sshd is the least of your
worries and I wouldn't install sshd at all.

> Actually the Cygwin doc does include instructions for accessing
> network shares when using ssh public key authentication.

…which boil down to the password being stored (obscured) on the machine
running sshd in order for sshd to obtain the necessary authentication
via password-based login.

> Once again, assumptions.  While I can't explicitly vouch for David's
> environment, as I do not have access to check, I can vouch for mine,
> and mine was configured using sshd_host_config, with the only changes
> after sshd_host_config being regarding TCP and X tunneling.

I have to again make an assumption, namely that if cyg_server is a local
account you've checked the C$ share of the same server that sshd is
running on.  That's bad enough, shouldn't happen and needs fixing, but
at least you wouldn't be able to access any network shares from other
servers that weren't otherwise accessible for everybody.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist]

On Sun, Feb 14, 2016 at 5:49 AM, Achim Gratz wrote:
> Erik Soderquist writes:
>> I would suspect Domain Admin for the Cyg_server account is a
>> requirement of David's environment, which neither of us know anything
>> about at present.  I know I've had to do things that were not "best
>> practice" due to corporate policy on more occasions than I care to
>> count.
>
> If that's the case, then security of the sshd is the least of your
> worries and I wouldn't install sshd at all.

Again, not always optional if you are not the one dictating corporate policy.

>> Actually the Cygwin doc does include instructions for accessing
>> network shares when using ssh public key authentication.
>
> …which boil down to the password being stored (obscured) on the machine
> running sshd in order for sshd to obtain the necessary authentication
> via password-based login.

Very true, but depending on the site configuration, there is at least
arguably more security in the password being stored on the machine
rather than passed across the network for the initial sshd connection.
This is very open to debate, but that debate isn't the topic of this
thread.  The point of this reference was that yes, there are designs
included to give network access to a user logged in via ssh using
public key authentication.


>> Once again, assumptions.  While I can't explicitly vouch for David's
>> environment, as I do not have access to check, I can vouch for mine,
>> and mine was configured using sshd_host_config, with the only changes
>> after sshd_host_config being regarding TCP and X tunneling.
>
> I have to again make an assumption, namely that if cyg_server is a local
> account you've checked the C$ share of the same server that sshd is
> running on.  That's bad enough, shouldn't happen and needs fixing, but
> at least you wouldn't be able to access any network shares from other
> servers that weren't otherwise accessible for everybody.

Valid assumption this time, yes I accessed c$ on the local host,
though in my past experience, I would expect it to work on remote
hosts as well in this scenario if the local and remote cyg_server
account use the same password.  For scripted installations across many
hosts, I would expect them to have the same password.  I can set this
up to test and confirm it, but that will take a bit of time.  Most of
my stations are *nix already.

I think the key point is that if no network password is stored using
the "passwd -R" option, then there should be absolutely no network
access at all in the current code/design, not a fall through to the
cyg_server account's network access, regardless of how much or little
network access that account has.

-- Erik.

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On Feb 14 13:36, Erik Soderquist wrote:
> I think the key point is that if no network password is stored using
> the "passwd -R" option, then there should be absolutely no network
> access at all in the current code/design, not a fall through to the
> cyg_server account's network access, regardless of how much or little
> network access that account has.

The problem is this:

I'm not aware of any explicit OS call which allows the process calling
CreateProcessAsUser to drop network credentials of the *caller* in the
child process running under another user token.

In fact, I'm not even aware of any call which allows to drop network
credentials even for the calling process, and that would be the wrong
thing to do anyway.

This is a clear cut case of "I need help" and "Patches gratefully
accepted".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

First let me say that I'm not too well-versed in coding and the ins and outs
of how processes utilize credentials when they are spawned. However, the
jist of it seems to be that if there are no credentials saved with passwd -R
to replace the current user token with that of the user that is SSH'd in,
then there is no way to change that token at all (or get rid of it) meaning
the token used when accessing a share will stay as the token of the caller -
namely cyg_server? Please correct me if I'm way off-base but that seems to
be my interpretation of this.

If that is the case, it seems this is an unintended side effect of the way
CYGWIN and sshd work together, and with the current state of Windows there
isn't really a way around it. And that's OK (I can work around it if that's
the case), I just wanted to get to the bottom of why this was happening and
let people know the situation because I wasn't sure if anyone was aware of
this behavior.

Thank you very much Erik and everyone else for the help with this. This is
my first time posting on these mailing lists and I appreciate people taking
the time to reproduce the issue and help work it out.

Thanks,

David

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Corinna Vinschen
Sent: Monday, February 15, 2016 4:11 AM
To: cygwin@cygwin.com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

On Feb 14 13:36, Erik Soderquist wrote:
> I think the key point is that if no network password is stored using 
> the "passwd -R" option, then there should be absolutely no network 
> access at all in the current code/design, not a fall through to the 
> cyg_server account's network access, regardless of how much or little 
> network access that account has.

The problem is this:

I'm not aware of any explicit OS call which allows the process calling
CreateProcessAsUser to drop network credentials of the *caller* in the child
process running under another user token.

In fact, I'm not even aware of any call which allows to drop network
credentials even for the calling process, and that would be the wrong thing
to do anyway.

This is a clear cut case of "I need help" and "Patches gratefully accepted".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]

On Feb 16 20:55, David Willis wrote:
> First let me say that I'm not too well-versed in coding and the ins and outs
> of how processes utilize credentials when they are spawned. However, the
> jist of it seems to be that if there are no credentials saved with passwd -R
> to replace the current user token with that of the user that is SSH'd in,
> then there is no way to change that token at all (or get rid of it) meaning
> the token used when accessing a share will stay as the token of the caller -
> namely cyg_server? Please correct me if I'm way off-base but that seems to
> be my interpretation of this.

It's wrong, but it's not easy to grok how this all works under the hood.
First of all, refering to
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview, only
method 1 should be affected.

There are two concepts at work here, one is the user token attached to
each process and defining group membership, permissions and privileges
of a process, the other one is the logon session in which the processes
are running.

The process started by sshd is running with a user token which belongs
to the user the process is supposed to run with.  The group memberships,
the permissions and privileges are set as desired.

However, the network credential are apparently not stored in the user token,
but are connected to the logon session.  And here comes the difference
between method 1 and the other two methods:

- In method 1, Cygwin creates a user token from scratch.  This occurs
  inside the Cygwin DLL itself and so in normal user space.  In Windows,
  there's no way to create a new logon session outside of the LSA.  And
  given that we don't have any credentials to authenticate the new user
  account (remember: we're trying to switch the user context without
  having to specify a password) we have no choice other than to run the
  new processes using the new user token under the logon session of the
  current user.  That's "cyg_server" usually.  Thus, the process has a
  user token for the correct user, but shares the logon session with the
  cyg_server process.

- When using method 2, the Cygwin DLL calls into the Cygwin authentication
  package which is running inside the LSA.  Therefore the authentication
  package can request a new logion session and attach it to the user token
  created inside the LSA.  So the new process is running in it's own
  logon session and thus not sharing the logon session with cyg_server.

- When using method 3, the token is created using the LogonUser function
  which calls into the LSA by itself.  The new user token is running in
  its own logon session.

> If that is the case, it seems this is an unintended side effect of the way
> CYGWIN and sshd work together, and with the current state of Windows there
> isn't really a way around it.

There might be a way around that.  I have a vague idea what to do to
create a new logon session, even when creating the token from scratch
per method 1, which would not share the network credentials of the
caller.  But it's just that yet, an idea.

If anybody has an idea how to perform this action, please share!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

On Feb 17 10:43, Corinna Vinschen wrote:
> On Feb 16 20:55, David Willis wrote:
> > First let me say that I'm not too well-versed in coding and the ins and outs
> > of how processes utilize credentials when they are spawned. However, the
> > jist of it seems to be that if there are no credentials saved with passwd -R
> > to replace the current user token with that of the user that is SSH'd in,
> > then there is no way to change that token at all (or get rid of it) meaning
> > the token used when accessing a share will stay as the token of the caller -
> > namely cyg_server? Please correct me if I'm way off-base but that seems to
> > be my interpretation of this.
> 
> It's wrong, but it's not easy to grok how this all works under the hood.
> First of all, refering to
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview, only
> method 1 should be affected.
> [bla, bla]
> > If that is the case, it seems this is an unintended side effect of the way
> > CYGWIN and sshd work together, and with the current state of Windows there
> > isn't really a way around it.
> 
> There might be a way around that.  I have a vague idea what to do to
> create a new logon session, even when creating the token from scratch
> per method 1, which would not share the network credentials of the
> caller.  But it's just that yet, an idea.

I implemented and tested the idea and it seems to work.  Note that the
underlying problem that we can't generate our own login session when using
method 1 persists.  However, the new code should avoid spilling cyg_server
credentials into the user session.

Please give the new Cygwin test release 2.5.0-0.4
(https://cygwin.com/ml/cygwin-announce/2016-02/msg00023.html) a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist]

On Thu, Feb 18, 2016 at 10:12 AM, Corinna Vinschen wrote:
<snip>>
> I implemented and tested the idea and it seems to work.  Note that the
> underlying problem that we can't generate our own login session when using
> method 1 persists.  However, the new code should avoid spilling cyg_server
> credentials into the user session.
>
> Please give the new Cygwin test release 2.5.0-0.4
> (https://cygwin.com/ml/cygwin-announce/2016-02/msg00023.html) a try.

I've installed the test release and am no longer able to reproduce the
issue; I get the expected "access denied" on all network shares as I
should on this test account.  (pub key auth, no password stored with
"passwd -R")

:)

-- Erik

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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Feb 18 12:10, Erik Soderquist wrote:
> On Thu, Feb 18, 2016 at 10:12 AM, Corinna Vinschen wrote:
> <snip>>
> > I implemented and tested the idea and it seems to work.  Note that the
> > underlying problem that we can't generate our own login session when using
> > method 1 persists.  However, the new code should avoid spilling cyg_server
> > credentials into the user session.
> >
> > Please give the new Cygwin test release 2.5.0-0.4
> > (https://cygwin.com/ml/cygwin-announce/2016-02/msg00023.html) a try.
> 
> I've installed the test release and am no longer able to reproduce the
> issue; I get the expected "access denied" on all network shares as I
> should on this test account.  (pub key auth, no password stored with
> "passwd -R")
> 
> :)

Thanks for testing, I really appreciate that.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist]

On Fri, Feb 19, 2016 at 6:10 AM, Corinna Vinschen wrote:
<snip>
> Thanks for testing, I really appreciate that.


You're very welcome  :)

-- Erik

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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

Hey, sorry I haven't had a chance to check in on this the last couple days

Thanks so much Corinna for implementing your idea in the new test release -
I haven't had a chance to test it yet but it sounds like it works as
expected. I really appreciate you taking the time to implement a fix for
this.

David

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Corinna Vinschen
Sent: Thursday, February 18, 2016 7:13 AM
To: cygwin@cygwin.com
Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?

On Feb 17 10:43, Corinna Vinschen wrote:
> On Feb 16 20:55, David Willis wrote:
> > First let me say that I'm not too well-versed in coding and the ins 
> > and outs of how processes utilize credentials when they are spawned. 
> > However, the jist of it seems to be that if there are no credentials 
> > saved with passwd -R to replace the current user token with that of 
> > the user that is SSH'd in, then there is no way to change that token 
> > at all (or get rid of it) meaning the token used when accessing a 
> > share will stay as the token of the caller - namely cyg_server? 
> > Please correct me if I'm way off-base but that seems to be my
interpretation of this.
> 
> It's wrong, but it's not easy to grok how this all works under the hood.
> First of all, refering to
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview, 
> only method 1 should be affected.
> [bla, bla]
> > If that is the case, it seems this is an unintended side effect of 
> > the way CYGWIN and sshd work together, and with the current state of 
> > Windows there isn't really a way around it.
> 
> There might be a way around that.  I have a vague idea what to do to 
> create a new logon session, even when creating the token from scratch 
> per method 1, which would not share the network credentials of the 
> caller.  But it's just that yet, an idea.

I implemented and tested the idea and it seems to work.  Note that the
underlying problem that we can't generate our own login session when using
method 1 persists.  However, the new code should avoid spilling cyg_server
credentials into the user session.

Please give the new Cygwin test release 2.5.0-0.4
(https://cygwin.com/ml/cygwin-announce/2016-02/msg00023.html) a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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

RE: Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

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.



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

Re: Possible Security Hole in SSHD w/ CYGWIN?

[Achim Gratz]

David Willis <david_willis <at> comcast.net> writes:
> 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).

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.


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

Possible Security Hole in SSHD w/ CYGWIN?

[David Willis]

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