Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation

Andrew McGill list2009@lunch.za.net
Thu Oct 22 06:53:00 GMT 2009


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



More information about the Cygwin mailing list