Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist <ErikSoderquist at gmail dot com>]

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