public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "David Willis" <david_willis@comcast.net>
To: <cygwin@cygwin.com>
Subject: RE: Possible Security Hole in SSHD w/ CYGWIN?
Date: Sun, 14 Feb 2016 01:29:00 -0000	[thread overview]
Message-ID: <025601d166c7$23eaa3c0$6bbfeb40$@comcast.net> (raw)
In-Reply-To: <CACoZoo14+ko0TZS1NtAh8R6DknAF_aoWAb1r+Nx3H+AWr_1o+w@mail.gmail.com>

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

  reply	other threads:[~2016-02-14  1:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-10  4:39 David Willis
2016-02-10  4:57 ` Stephen John Smoogen
2016-02-10  5:21   ` David Willis
2016-02-12 22:27     ` David Willis
2016-02-13  8:34       ` Achim Gratz
2016-02-13 21:15         ` David Willis
2016-02-14  0:34           ` Erik Soderquist
2016-02-14  1:29             ` David Willis [this message]
2016-02-14  1:48               ` Erik Soderquist
2016-02-14 10:49           ` Achim Gratz
2016-02-14  0:14         ` Erik Soderquist
2016-02-14  1:37           ` David Willis
2016-02-14 10:49           ` Achim Gratz
2016-02-14 18:36             ` Erik Soderquist
2016-02-15 12:11               ` Corinna Vinschen
2016-02-17  4:55                 ` David Willis
2016-02-17  9:43                   ` Corinna Vinschen
2016-02-18 15:13                     ` Corinna Vinschen
2016-02-18 17:10                       ` Erik Soderquist
2016-02-19 11:10                         ` Corinna Vinschen
2016-02-19 16:38                           ` Erik Soderquist
2016-02-20 19:53                       ` David Willis
2016-02-13  1:04     ` Erik Soderquist
2016-02-13 20:04       ` David Willis
  -- strict thread matches above, loose matches on Subject: below --
2016-02-09 15:56 David Willis
2016-02-09  6:43 David Willis
2016-02-09  7:53 ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='025601d166c7$23eaa3c0$6bbfeb40$@comcast.net' \
    --to=david_willis@comcast.net \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).