From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82449 invoked by alias); 13 Feb 2016 08:34:13 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 82435 invoked by uid 89); 13 Feb 2016 08:34:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=CDs, authenticate, credentials, editrights X-HELO: mail-in-16.arcor-online.net Received: from mail-in-16.arcor-online.net (HELO mail-in-16.arcor-online.net) (151.189.21.56) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Sat, 13 Feb 2016 08:34:10 +0000 Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id 3q2Q3325nfzCNrr for ; Sat, 13 Feb 2016 09:34:07 +0100 (CET) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 45382563A5F for ; Sat, 13 Feb 2016 09:34:07 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net 3q2Q331GZqz7lv5 Received: from Gertrud (p54B4660E.dip0.t-ipconnect.de [84.180.102.14]) (Authenticated sender: stromeko@arcor.de) by mail-in-06.arcor-online.net (Postfix) with ESMTPSA id 3q2Q331GZqz7lv5 for ; Sat, 13 Feb 2016 09:34:06 +0100 (CET) From: Achim Gratz To: cygwin@cygwin.com Subject: Re: Possible Security Hole in SSHD w/ CYGWIN? References: <019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.net> Date: Sat, 13 Feb 2016 08:34:00 -0000 In-Reply-To: <023901d165e4$925507d0$b6ff1770$@comcast.net> (David Willis's message of "Fri, 12 Feb 2016 14:27:34 -0800") Message-ID: <87d1s1c8ld.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-02/txt/msg00185.txt.bz2 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