* Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation @ 2009-09-21 8:41 Andrew McGill 2009-09-21 16:05 ` Dave Korn 0 siblings, 1 reply; 5+ messages in thread From: Andrew McGill @ 2009-09-21 8:41 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation 2009-09-21 8:41 Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation Andrew McGill @ 2009-09-21 16:05 ` Dave Korn 2009-09-21 18:39 ` Christopher Faylor 2009-09-23 6:26 ` Andrew McGill 0 siblings, 2 replies; 5+ messages in thread From: Dave Korn @ 2009-09-21 16:05 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation 2009-09-21 16:05 ` Dave Korn @ 2009-09-21 18:39 ` Christopher Faylor 2009-09-23 6:26 ` Andrew McGill 1 sibling, 0 replies; 5+ messages in thread From: Christopher Faylor @ 2009-09-21 18:39 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation 2009-09-21 16:05 ` Dave Korn 2009-09-21 18:39 ` Christopher Faylor @ 2009-09-23 6:26 ` Andrew McGill 2009-10-22 6:53 ` Andrew McGill 1 sibling, 1 reply; 5+ messages in thread From: Andrew McGill @ 2009-09-23 6:26 UTC (permalink / raw) To: cygwin; +Cc: Dave Korn 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation 2009-09-23 6:26 ` Andrew McGill @ 2009-10-22 6:53 ` Andrew McGill 0 siblings, 0 replies; 5+ messages in thread From: Andrew McGill @ 2009-10-22 6:53 UTC (permalink / raw) To: cygwin; +Cc: Dave Korn 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-10-22 6:53 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-21 8:41 Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation Andrew McGill 2009-09-21 16:05 ` Dave Korn 2009-09-21 18:39 ` Christopher Faylor 2009-09-23 6:26 ` Andrew McGill 2009-10-22 6:53 ` Andrew McGill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).