Date: Sun, 19 Jul 1998 19:48:30 -0600 From: Warner Losh <imp@village.org> To: Archie Cobbs <archie@whistle.com> Cc: brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: The 99,999-bug question: Why can you execute from the stack? Message-ID: <199807200148.TAA07794@harmony.village.org> In-Reply-To: Your message of "Sun, 19 Jul 1998 18:02:04 PDT." <199807200102.SAA07953@bubba.whistle.com> References: <199807200102.SAA07953@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199807200102.SAA07953@bubba.whistle.com> Archie Cobbs writes: : As an almost-example of why executing on the stack is not completely : crazy, consider JIT-compiling Java runtimes like kaffe. These dynamically : compile Java methods into i386 executable instructions, then execute : those methods. Kaffe actually does this on the heap I think, but it just : as reasonable if it wanted to do it on the stack (eg, perhaps some kind : of temporary method, trampoline code to get things going, etc). I think that most, but not all, of the problems can be fixed by making the stack non-executables for set[gu]id binaries. this will fix the attacks where elevated privs are used to get access. however, i'm not completely sure about this because there are many problems with this idea. not the least of which is that it feels like a bandaide to me. One option would be to have an executable page of memory on a per process basis. This would allow a place to allow signals to happen. Since the kernel, and not the userland, would write the code to here, it wouldn't be too bad. Except for the per process part.... One way to "solve" this problem would be to have all calls push a "guard" page that could be unmapped. This would solve the stack overflow problems, but not all overflows. Again, this is at a huge price which I don't think I'd want to pay. Another high cost option would be to have a purify/checker-like functionality compiled into everything and cause a segv or some other generally fatal signal. This would solve all the overflows, but again at a huge price. If there was a silver bullet, I sure would like to know what it is... Warner 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?199807200148.TAA07794>