This is the mail archive of the
mailing list for the Cygwin project.
Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation
- From: Andrew McGill <list2009 at lunch dot za dot net>
- To: cygwin at cygwin dot com
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Date: Thu, 22 Oct 2009 08:53:29 +0200
- Subject: Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation
- References: <email@example.com> <4AB7A797.firstname.lastname@example.org> <email@example.com>
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
* 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
> > > 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
> just for fun, and something like
> 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple