X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org From: "Dave Korn" To: "'Cygwin-L'" References: <2D9E96311DCA4C48BF185EA6928BC7BB026A1822 AT asc-mail DOT int DOT ascribe DOT com> <20070918155829 DOT 1648 AT blackhawk> <20070918151831 DOT GA27067 AT trixie DOT casa DOT cgf DOT cx> <46F238A7 DOT 9090807 AT etr-usa DOT com> Subject: RE: Is there someone offering cygwin paid support? Date: Thu, 20 Sep 2007 16:53:37 +0100 Message-ID: <015a01c7fb9e$69ec5910$2e08a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46F238A7.9090807@etr-usa.com> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On 20 September 2007 10:09, Warren Young wrote: > Will Parsons wrote: >> why would cygwin be less secure? > Just one way it could fail is if there is a buffer overflow in the > implementation of one of Cygwin's interfaces, and your "100% secure" > program calls it. It's then only a matter of time for a skilled hacker > to turn that buffer overflow into an arbitrary code execution > vulnerability. At minimum, the hacker will then have the privileges of > the program. Once the hacker has local access, chances are good that he > can parlay that into a privilege escalation attack, and it's Game Over > for you. It's worse than that - he's dead, Jim. Cygwin does actually introduce one gaping security hole: the shared memory section. It's an artifact of the fact that we're trying to emulate an entire posix system, and so we need to maintain global state across multiple processes. Because we're not the kernel, we can't just keep process lists and so on in kernel memory where all processes can access them, so we have to find a way of sharing memory between different processes in used mode; the shared section is a way of doing this. Unfortunately, that means that low-privilege processes (running as a limited user) and high-privilege processes (running services as SYSTEM, for example) have an uncontrolled connection between them. It's entirely likely that a guest user, by manipulating the contents of the shared memory section, could inject code into or otherwise divert or seize control of any SYSTEM-level cygwin process. That's yer privilege escalation right there, that is. cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/