This is the mail archive of the
mailing list for the Cygwin project.
Re: Possible Security Hole in SSHD w/ CYGWIN?
- From: Erik Soderquist <ErikSoderquist at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 14 Feb 2016 13:36:09 -0500
- Subject: Re: Possible Security Hole in SSHD w/ CYGWIN?
- Authentication-results: sourceware.org; auth=none
- References: <019c01d163bc$fe2fc500$fa8f4f00$ at comcast dot net> <CANnLRdhVrFcveO_jKb3_x=44WMJNO33DPnsJZ12Wus3U7Wo_fQ at mail dot gmail dot com> <019e01d163c2$d678c7e0$836a57a0$ at comcast dot net> <023901d165e4$925507d0$b6ff1770$ at comcast dot net> <87d1s1c8ld dot fsf at Rainer dot invalid> <CACoZoo3R4CDcgTMMex9QZ=Wh9a8CDvyUHpqj5+Br5xYFvGHvuQ at mail dot gmail dot com> <87a8n38t3r dot fsf at Rainer dot invalid>
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
> 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple