Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation
Andrew McGill
list2009@lunch.za.net
Thu Oct 22 06:53:00 GMT 2009
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
More information about the Cygwin
mailing list