Re: Possible Security Hole in SSHD w/ CYGWIN?

[Erik Soderquist <ErikSoderquist at gmail dot com>]

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