From owner-freebsd-security Sun Jul 19 18:46:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25584 for freebsd-security-outgoing; Sun, 19 Jul 1998 18:46:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA25569 for ; Sun, 19 Jul 1998 18:46:54 -0700 (PDT) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0yy524-0003gh-00; Sun, 19 Jul 1998 19:46:28 -0600 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id TAA07794; Sun, 19 Jul 1998 19:48:31 -0600 (MDT) Message-Id: <199807200148.TAA07794@harmony.village.org> To: Archie Cobbs Subject: Re: The 99,999-bug question: Why can you execute from the stack? Cc: brett@lariat.org (Brett Glass), security@FreeBSD.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> Date: Sun, 19 Jul 1998 19:48:30 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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