X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4AB7A797.6090405@gmail.com> Date: Mon, 21 Sep 2009 17:19:35 +0100 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Write access for BUILTIN\USERS - cygwin privilege escalation vulnerability for Windows 2008 default installation References: <200909211041 DOT 17032 DOT list2009 AT lunch DOT za DOT net> In-Reply-To: <200909211041.17032.list2009@lunch.za.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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