Date: Wed, 24 Jun 1998 17:29:39 +0800 From: Peter Wemm <peter@netplex.com.au> To: dg@root.com Cc: Nicholas Charles Brawn <ncb05@uow.edu.au>, security@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: non-executable stack? Message-ID: <199806240929.RAA11498@spinner.netplex.com.au> In-Reply-To: Your message of "Sun, 21 Jun 1998 23:19:50 MST." <199806220619.XAA16784@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > >I was pondering the following after reading about solaris 2.6's > >non-executable stack option. > > > >1. How feasible is it to implement a non-executable stack kernel option? > >2. If it *is* feasible, what do people think of a sysctl-based interface > >to enable/disenable it? > >3. If both 1 & 2 were implemented, how about making it impossible to > >disenable at say.. securelevel >= 1? > > > >If I remember the discussions on bugtraq right, a non-exec patch isn't a > >cure-all for buffer overflow attacks. However it would be an overall > >security enhancement and prevent many script-based attacks. > > > >What are peoples thoughts on this? > > I believe that making the stack non-exec will break the signal trampoline > in FreeBSD. Although this may have changed in recent times without me > noticing. Bruce? Peter? Yes, it would, if the entire stack was non-executable. However.. since the x86 can't turn off execute permission at the page level, it has to use the segments system, and this is byte or paragraph addressible. I'm not totally familiar with the Linux patches to do this, in particular I don't know if the user segment descriptor lengths are "shrunk" to prevent %cs and/or %ds addressing of the stack (ouch!), or whether there's a new segment to contain the stack and %ss is loaded with that, or something else entirely. It might be enough to shorten the %cs segment to prevent stack executability, but that doesn't help threaded programs with their own stacks, and it sounds too easy. :-) And it doesn't solve the trampoline problem. The reason we have the trampoline at all is so that we can have the process do a 'sigreturn()' syscall after calling the handler. Making the process execute the handler directly wouldn't be too hard since it'd be just register and stack frame twiddling, but getting it to execute the syscall that's needed to resture the pre-signal context (some of which is privileged) is the problem. A binary interface modification would work (ie: have signal, sigaction etc use their own trampoline directly), but that would break binary compatability in a big way. The cost of an extra page outside the stack and within the user %cs space to provide the trampoline would not be insignificant to everybody. On a system with 1000 processes, an extra 4K page is 4MB total. On the other hand, ram is cheap at the moment, perhaps this is a tradeoff that people would be happy to make? Incidently, I have found that causing 'int 0x80' (the linux syscall entry point) in a bsd executable to immediately kill and core dump the process and printf a console message has been quite enlightening on shell server machines over the past year or so. > -DG Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806240929.RAA11498>