From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60498 invoked by alias); 14 Feb 2016 01:48:07 -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 60413 invoked by uid 89); 14 Feb 2016 01:48:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Achim's, achims, plaintext, Achims X-HELO: mail-lf0-f46.google.com Received: from mail-lf0-f46.google.com (HELO mail-lf0-f46.google.com) (209.85.215.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 14 Feb 2016 01:48:02 +0000 Received: by mail-lf0-f46.google.com with SMTP id l143so71417159lfe.2 for ; Sat, 13 Feb 2016 17:48:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=O9TP8YpCab9PC7AZUhJ8Z1Add/Db5Rcg0R+ukzhy8AQ=; b=gwtxbMjKGc8olPmzISS94ZHO8f/J7nw6/Ne9e7xHLyrEEcHISZ2JrbxXRjFLJsWV+V oRwLk0GUuCU+elCcBnT3joxeAMex3ia2EOkp7UBVYk1ZggPVJL+3AStq+8Gm1GN6hk4o yJ+MQdPbKzVCwzP6lpgPS2LBF81j/f96k+paWQXVM/aveYNbHlHw6rst+Ap3epymGLdy UltGlH729P/47/Hw4Ugansb5tESXc29SUG4jgQR6ysIjeuz2apzKYK+spK7syhZLAE/0 I/lz1TazX3u0KEDnD+meDZ1BRBu8Xf7L7nshxmAUMy6wUDNlOr4Fa66Zm2YU+TDNuviw l7HA== X-Gm-Message-State: AG10YORu/1VRCgwT9FLWnpIFV2Qm87tMWIfCPzUxr0uT/BXiTW1B/bnG9kID91JMz5LQacRDlm16ZdQqpyCJ/g== MIME-Version: 1.0 X-Received: by 10.25.153.130 with SMTP id b124mr3863590lfe.81.1455414478551; Sat, 13 Feb 2016 17:47:58 -0800 (PST) Received: by 10.25.86.196 with HTTP; Sat, 13 Feb 2016 17:47:58 -0800 (PST) In-Reply-To: <025601d166c7$23eaa3c0$6bbfeb40$@comcast.net> References: <019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.net> <87d1s1c8ld.fsf@Rainer.invalid> <024901d166a3$a6930390$f3b90ab0$@comcast.net> <025601d166c7$23eaa3c0$6bbfeb40$@comcast.net> Date: Sun, 14 Feb 2016 01:48:00 -0000 Message-ID: Subject: Re: Possible Security Hole in SSHD w/ CYGWIN? From: Erik Soderquist To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00208.txt.bz2 On Sat, Feb 13, 2016 at 8:29 PM, David Willis wrote: > 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)... It is encrypted, but since cygwin needs to be able to use that password to authenticate against Windows processes for the network authentication, it is a reversible encryption, so it would be relatively easy for a determined attacker to code their own reversal of the encryption. The full doc calls it obfuscation to avoid confusion with the usual one way encryption done on passwords. I have not looked at where in the registry it is stored or what the permissions on those keys are, but I would assume local admin privilege is required to access it since the doc also states users can't save the password if the cygwin processes are not running and cyg_server requires local admin; logical extension, since the process already requires local admin, make local admin required to read the encrypted saved passwords. (Again, this is my assumption; I have not looked it up). > 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. "best", possibly, though may or may not be feasible, and "best" is often very subjective. Also would reduce the "Linux look and feel" that is one of the goals on cygwin. > 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. Yes... I was very surprised to say the least that I could access the c$ admin share with a non-admin account... that opens things like replacing core OS files very easily to anyone who authenticates with a public key. -- 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