Subject: Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation
From: Andrew McGill <[email-masked]>
To: [email-masked]
Cc: Dave Korn <[email-masked]>
Date: Wed, 23 Sep 2009 08:26:10 +0200
List-Id: <cygwin.cygwin.com>

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