X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
From: Andrew McGill <list2009 AT lunch DOT za DOT net>
To: cygwin AT cygwin DOT com
Subject: Re: Write access for BUILTIN\USERS - cygwin privilege escalation  vulnerability for Windows 2008 default installation
Date: Thu, 22 Oct 2009 08:53:29 +0200
User-Agent: KMail/1.12.1 (Linux/2.6.24-19-generic; KDE/4.3.1; i686; ; )
Cc: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
References: <200909211041 DOT 17032 DOT list2009 AT lunch DOT za DOT net> <4AB7A797 DOT 6090405 AT gmail DOT com> <200909230826 DOT 10702 DOT list2009 AT lunch DOT za DOT net>
In-Reply-To: <200909230826.10702.list2009@lunch.za.net>
MIME-Version: 1.0
Content-Type: Text/Plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200910220853.29286.list2009@lunch.za.net>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Here a workaround for this wide open flaming security hole in the default 
CYGWIN install.  The workaround may or may not be correct:

 * Browse to C:\
 * Right-click on "cygwin" folder
 * Choose "Sharing and security"
 * Choose "Advanced"
 * Remove the tick mark from "Allow inheritable permissions from the parent to 
propagate ..."
 * Select "Copy" when the intimidating popup pops up
 * "Inherited from" column now says "Not inherited"
 * Select "Alllow .. USERS ... Special", and click "Remove"
 * Select "OK" .. and wait some time ...
 * Click "OK" again (what does that do?)

If you do not do this, you are giving pwnership of all cygwin user accounts to 
anyone in BUILTIN/USERS.

To get some semblance of security (ie, non-world-writeableness), I also had to 
set permissions on /home for some reason ...
	chmod 755 /home /home/*

It may work to change the default install location to %WINDIR%\cygwin, since 
subfolders of that inherit more secure permissions than subfolders of C:\


On Wednesday 23 September 2009 08:26:10 Andrew McGill wrote:
> On Monday 21 September 2009 18:19:35 Dave Korn wrote:
> > Andrew McGill wrote:
> > >   I can pwn the box from IIS by writing content to
> > > these files -- and not much creativity is needed to think of many more:
> >
> >   Waittaminnit, are you saying IIS by default lets you write any file you
> >  like anywhere on the server and relies on ACLs to save it?  I think you
> >  have a bigger problem than the perms on your Cygwin folder!  (Or are you
> >  just assuming that a directory traversal attack is likely to be possible
> >  anywhere webdav or ftp are turned on?)
> 
> You don't get to write quite anywhere -- I'll get to that in a moment.
> However, we do not have the luxury of running only trusted code, so we need
> the box to be locked down.   If you have IIS, install aspshell.asp from
> aspshell.sourceforge.net -- it is really quite entertaining.  pwn ur own
>  box.
> 
> > > Feature request: The cygwin installer should set permissions on
> > > c:\cygwin to be the same as %windir%, and not trust the operating
> > > system to do the "right thing".
> >
> >   Seems sensible to me.  I thought MS had gone and locked down the perms
> > on the root drives in every OS since XP, in order to defeat the
> >  "C:\Program.exe" attack?  I'm really surprised that a default
> > unprivileged user on a server 2k8 system is permitted write access to the
> > drive root, that's just bizarre.
> 
> MS did the bare minimum, it seems, and stopped write access to only c:\. 
>  The ACL for write permission is defined in c:\ and applies to new
>  directories created without due care in c:\ (and d:\ too, as far as I can
>  tell).  This means that while you cannot create c:\Program.exe and pwn the
>  desktop, you can create
> 	c:\cygwin\Program.exe
> just for fun, and something like
> 	c:\cygwin\home\Administrator\.ssh\authorised_keys
> or
> 	c:\cygwin\usr\local\bin\ls.exe
> to pwn the whole machine.  The permissions in effect are similar to what
>  you would have after ... find 'c:\newdir' -type d | xargs -0 chmod 1777
> 
> > Also, this should be emphasised: Cygwin is fundamentally insecure versus
> > cross-user privilege/process stealing attacks.
> >
> >  Not being part of the OS, we can't prevent user processes from attacking
> > each other via manipulating the shared cygheap state.  Effectively this
> >  means different users' processes are not isolated from each other, so if
> >  for example you're running a service under one of the nt_authority
> >  accounts, an unprivileged user logged on to the same box could escalate
> >  their privileges to its level.
> >
> >   Therefore Cygwin should never be deployed to provide services to
> >  untrusted users on a 'net-facing server.  It's just not a real OS(*).
> 
> So on the net facing box with untrusted code from hell, is it sufficient to
> deny the default write access to BUILTIN\Users, or is it also necessary to
> deny read access to BUILTIN\Users?  Or is denying read access also
> insufficient, and running cygwin and sshd is a security "fail"?
> 
> &:-)
> 
> --
> 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
> 

-- 
remove regular file `.signature'?

--
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