This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]