From owner-freebsd-hackers Mon Mar 3 12:31:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA25668 for hackers-outgoing; Mon, 3 Mar 1997 12:31:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA25663 for ; Mon, 3 Mar 1997 12:31:14 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08451; Mon, 3 Mar 1997 13:25:59 -0700 From: Terry Lambert Message-Id: <199703032025.NAA08451@phaeton.artisoft.com> Subject: Re: Removing execute privs from stack pages To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 3 Mar 1997 13:25:58 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199703031825.NAA17682@skynet.ctr.columbia.edu> from "Bill Paul" at Mar 3, 97 01:25:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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.