Date: Sat, 29 Jun 2002 17:50:45 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: Jake Burkholder <jake@locore.ca>, arch@FreeBSD.ORG Subject: Re: Time to make the stack non-executable? Message-ID: <3D1E55E5.998DCEBA@mindspring.com> References: <3D1E28ED.B67A5271@FreeBSD.org> <3D1E3126.C96FFAA5@mindspring.com> <20020629185554.I71376@locore.ca> <20020629232603.GA1361@gnuppy.monkey.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Huey wrote: > On Sat, Jun 29, 2002 at 06:55:54PM -0400, Jake Burkholder wrote: > > > Doug Barton wrote: > > > o Java; specifically, JITs may rely on an executable > > > stack. Neither of us knows if this is true, for > > > sure. > > I didn't get to see the original post, but... > > Hehe, I definitely know the answer to this. The HotSpot compiler > uses OSR (on stack routines) to deal with certain exception > situations. If that doesn't mean that it puts a routine on a stack > for execution, then I don't know what does. Many modern language > runtimes use these kind of conventions, so it's bound to create > problems with other systems. As I said in the original post, Sean and I are both aware of the possibility that some software will be unable to run after this. One way to potentially work around this is to allow the stack pages to be marked executable by explicit linking with an alternate crt0.o, or, more usefully, by way of an attribute on the file (e.g. a "chflags"). My pet fears were Java, LISP, and Forth, and that's just the short list. The real question is whether or not it would interfere with KSE itself (Julian says "no"), and whether or not it would interfere with anything else. I know that it will break signals, unless the signals system is modified to pass the return address as an argument. Stepping on that code is really dangerous now (as I pointed out to Sean), sine it's one of the places that's really in flux (particularly on the Alpha), according to Julian. All of this adds up to "why it's an appropriate topic for -arch instead of just a set of patches that does it". Jake says he's running with his stack this way (locally) on the SPARC64. I guess I'd like to know why the patches are only local (if there is something he knows it will break, or is holding it back for some other reason), and what problems people see for i386. It would be really nice to be immune from stack overflow based hacks. This also implys that we need to make sure that anything that mmap's code and data (e.g. dlopen) doesn't set the execute attribute on the data pages. This is more of a problem in third party code that implements its own modules system from scratch. Is this a worthwhile project? It seems to me that it would fix the "Apache problem" that led to the news article about FreeBSD being exploitable. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D1E55E5.998DCEBA>