From owner-freebsd-hackers  Tue Mar  4 10:17:43 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id KAA05304
          for hackers-outgoing; Tue, 4 Mar 1997 10:17:43 -0800 (PST)
Received: from rover.village.org (rover.village.org [204.144.255.49])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA05298
          for <hackers@freebsd.org>; Tue, 4 Mar 1997 10:17:40 -0800 (PST)
Received: from rover.village.org [127.0.0.1] 
	by rover.village.org with esmtp (Exim 0.56 #1)
	id E0w1ymE-0000oj-00; Tue, 4 Mar 1997 11:17:26 -0700
To: Bill Paul <wpaul@skynet.ctr.columbia.edu>
Subject: Re: Removing execute privs from stack pages 
Cc: hackers@freebsd.org
In-reply-to: Your message of "Mon, 03 Mar 1997 13:25:23 EST."
		<199703031825.NAA17682@skynet.ctr.columbia.edu> 
References: <199703031825.NAA17682@skynet.ctr.columbia.edu>  
Date: Tue, 04 Mar 1997 11:17:26 -0700
From: Warner Losh <imp@village.org>
Message-Id: <E0w1ymE-0000oj-00@rover.village.org>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199703031825.NAA17682@skynet.ctr.columbia.edu> Bill Paul writes:
: Inquiring minds want to know. I can't think of any particular reason
: why you'd want the stack pages to be executable anyway, but again I don't
: know enough details to judge. Could be I'm totally out in left field here.

The signal code in the kernel uses trampolines on the stack, whcih
must be executable.  gcc and g++ will sometimes generate trampolines
for various language constructs that depend on the stack being
executable as well.

The only way that I can think of to stop the buffer overflow stuff
with help from the system, short of fixing the above, is to have a
"red zone" between each stack frame that is unmapped and that any
writes to will cause an execption to happen.  This breaks a lot of
current binaries, but should be proof against the stack overflow
attacks.  Too bad the performance of such a system will suck really
really badly :-(.

Even making the stack non-executable will not solve the problem.  It
is possible to use overflows to overwrite function pointers in .data
or .bss area that are called through (although this is much much
harder).

Warner