From owner-freebsd-hackers Thu Mar 6 21:07:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA14740 for hackers-outgoing; Thu, 6 Mar 1997 21:07:08 -0800 (PST) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA14730 for ; Thu, 6 Mar 1997 21:07:00 -0800 (PST) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.6.12/8.6.12) with ESMTP id VAA05712; Thu, 6 Mar 1997 21:17:34 -0800 Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id VAA29447; Thu, 6 Mar 1997 21:06:31 -0800 (PST) Date: Thu, 6 Mar 1997 21:06:31 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199703070506.VAA29447@dog.farm.org> To: jlemon@americantv.com (Jonathan Lemon) Cc: freebsd-hackers@freebsd.org Subject: Re: Removing execute privs from stack pages Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19970303144224.03031@right.PCS> you wrote: > On Mar 03, 1997 at 01:25:23PM -0500, Bill Paul wrote: > > I've got a question for you VM/i386 gurus out there. Recently, somebody > > showed me a script for Solaris/SPARC to short-circuit buffer overflow > > security holes by removing execute access from the user stack pages. > > Doing this does not prevent buffer overflows and stack corruption from > > happening, but it does prevent any malicious code written to the stack > > from being executed, thus rendering the overflow condition harmless. > > (Well, sort of: the overflow can still crash the process, but at least > > it prevents suid/sgid programs with buffer overflow bugs from giving > > away privs.) > > > > My question is: can this sort of thing be done with FreeBSD/i386? From > Not at the moment. The signal trampoline code is currently written onto > the user stack by the kernel (see machdep.c). I suppose that if the > trampoline code is moved out of the UPAGES area, then it might be possible. Also, gcc generates trampoline code on the stack in some cases; passing of ointers-to-nested-functions as args involves that (that's GCC extension to C), and there may be others. -- Two mistakes of a programmer: to born, and to select a profession.