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

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

[Andrew McGill]

Hi,

I ran setup.ext to install cygwin in c:\cygwin on a (fairly) fresh 
installation of Windows Server 2008.  On this server, the permissions of C:\ 
were set to allow new files to be created in subdirectories by BUILTIN\Users.  

The cygwin folder inherited from the default permissions on C:\ the following 
ACL:

[C:\cygwin] icacls c:\cygwin
c:\cygwin NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
          BUILTIN\Administrators:(I)(OI)(CI)(F)
          BUILTIN\Users:(I)(OI)(CI)(RX)
          BUILTIN\Users:(I)(CI)(AD)   <<<<<<< AAAAAAAARGH!
          BUILTIN\Users:(I)(CI)(WD)   <<<<<<< AAAAAAAARGH!
          ZEROTOOL\Administrator:(I)(F)
          CREATOR OWNER:(I)(OI)(CI)(IO)(F)

This allows ANY member of BUILTIN/Users, including nt authority\network 
service to create files.  I can pwn the box from IIS by writing content to 
these files -- and not much creativity is needed to think of many more:

	c:/cygwin/home/Administrator/.ssh/authorized_keys
	c:/cygwin/home/Administrator/.bashrc
	c:/cygwin/home/Administrator/.bash_logout
	c:/cygwin/home/Administrator/.bash_profile
	c:/cygwin/home/Administrator/.vimrc

This permission was default on the system - it seems to be there on Windows 
2003 as well, and maybe before that.  Folders like c:\windows and c:\inetpub 
have explicit permissions for builtin/users.  Perhaps this is some kind of 
secret best practice that cygwin is missing out on?  If not, it's merely a 
series of unfortunate events that adds up to a privilege escalation 
vulnerability, and you really should understand windows ACL's before running 
cygwin.

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

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

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

[Dave Korn]

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

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


  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(*).

    cheers,
      DaveK
-- 
(*) - In security terms, think of it as a type-2 VM from which it is known to
be inherently possible owing to the architectural design to escape from the
guest; would you want to run that VM under a system-level account?


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

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

[Christopher Faylor]

On Mon, Sep 21, 2009 at 05:19:35PM +0100, Dave Korn wrote:
>  Therefore Cygwin should never be deployed to provide services to untrusted
>users on a 'net-facing server.  It's just not a real OS(*).

Cygwin is not a floor wax either.  It's just barely a dessert topping.

cgf

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

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

[Andrew McGill]

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

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

[Andrew McGill]

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