Date: Mon, 3 Mar 1997 13:25:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: hackers@freebsd.org Subject: Re: Removing execute privs from stack pages Message-ID: <199703032025.NAA08451@phaeton.artisoft.com> In-Reply-To: <199703031825.NAA17682@skynet.ctr.columbia.edu> from "Bill Paul" at Mar 3, 97 01:25:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? The short answer: "no". The long answer: there is no distinction between "readable" and "executable" in the hardware mapping interpretation. You *might* be able to ensure non-writability -- but not on all hardware, since a write fault is not generated in kernel space except on newer processors, and then only if the bit is enabled (write fault handling on i386 is typically emulated in the copyin/copyout). This would require execution time overhead to force non-contiguity of the mapping boundry so that it could be determined if the page was code or data at fault time... a lot of overhead for little protection. Even with this protection, obviously "su" must be able to invoke a shell in the success case. The stack overflow for the return address could easily point the return address to the valid exec code instead of returning and going through the compare which fails and aborts the exec. So you would also have to be sure that no code existed, such that if it were interpreted on any particular byte boundry, it would result in a shell. Frankly, I wonder how LISP and FORTH can run on such a system. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703032025.NAA08451>