Date: Tue, 04 Mar 1997 11:17:26 -0700 From: Warner Losh <imp@village.org> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@freebsd.org Subject: Re: Removing execute privs from stack pages Message-ID: <E0w1ymE-0000oj-00@rover.village.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0w1ymE-0000oj-00>