From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22884 invoked by alias); 22 Oct 2009 06:53:40 -0000 Received: (qmail 22874 invoked by uid 22791); 22 Oct 2009 06:53:39 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from pizza.lunch.za.net (HELO pizza.lunch.za.net) (80.68.92.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Oct 2009 06:53:35 +0000 Received: from spectrum.zx ([196.210.237.159]) (authenticated bits=0) by pizza.lunch.za.net (8.13.8/8.14.3/ho) with ESMTP id n9M6rTgA023623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 08:53:31 +0200 From: Andrew McGill To: cygwin@cygwin.com Subject: Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation Date: Thu, 22 Oct 2009 06:53:00 -0000 User-Agent: KMail/1.12.1 (Linux/2.6.24-19-generic; KDE/4.3.1; i686; ; ) Cc: Dave Korn References: <200909211041.17032.list2009@lunch.za.net> <4AB7A797.6090405@gmail.com> <200909230826.10702.list2009@lunch.za.net> In-Reply-To: <200909230826.10702.list2009@lunch.za.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910220853.29286.list2009@lunch.za.net> X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2009-10/txt/msg00543.txt.bz2 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