Date: Sun, 19 Jul 1998 20:10:39 -0600 From: Brett Glass <brett@lariat.org> To: Warner Losh <imp@village.org>, Archie Cobbs <archie@whistle.com> Cc: security@FreeBSD.ORG Subject: Re: The 99,999-bug question: Why can you execute from the stack? Message-ID: <199807200210.UAA07188@lariat.lariat.org> In-Reply-To: <199807200148.TAA07794@harmony.village.org> References: <Your message of "Sun, 19 Jul 1998 18:02:04 PDT."<199807200102.SAA07953@bubba.whistle.com> <199807200102.SAA07953@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:48 PM 7/19/98 -0600, Warner Losh wrote: >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. I think it's fundamentally good architecture and a good general precaution to keep code off the stack. After all, the original Intel architecture was set up so that you couldn't execute from a stack segment without doing special aliasing; they did this with security and reliability in mind. Alas, most "flat model" OSes turn off this mechanism. >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. That's certainly one idea. It wouldn't even have to take up physical memory until it was needed, saving space. Another way to do it would be to reserve some space at the end of the executable's last existing code page. If the thunk isn't large, the odds are excellent that it'll fit there. In which case, there's no wasted memory and nothing special to allocate. If it doesn't fit, allocate an extra page at load time, or map it but defer allocation until a signal must be handled. The important thing is to keep the code off of the stack and also out of the global data space. >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. We can avoid this; see above. >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. I agree that this is excessive. >If there was a silver bullet, I sure would like to know what it is... There's no "silver bullet." But putting the thunk on the stack is in some ways trickier than putting it elsewhere, since the stack could underflow when you tried to make room. Having a known location is easier. --Brett 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?199807200210.UAA07188>