Date: Mon, 20 Jul 1998 12:26:52 -0500 From: Karl Denninger <karl@mcs.net> To: Brett Glass <brett@lariat.org> Cc: Alexandre Snarskii <snar@paranoia.ru>, Warner Losh <imp@village.org>, Archie Cobbs <archie@whistle.com>, security@FreeBSD.ORG Subject: Re: The 99,999-bug question: Why can you execute from the stack? Message-ID: <19980720122652.35370@mcs.net> In-Reply-To: <199807201714.LAA19993@lariat.lariat.org>; from Brett Glass on Mon, Jul 20, 1998 at 11:14:33AM -0600 References: <199807200148.TAA07794@harmony.village.org> <199807200102.SAA07953@bubba.whistle.com> <199807200148.TAA07794@harmony.village.org> <19980720152932.42290@nevalink.ru> <199807201714.LAA19993@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett is right. First and foremost, using segmentation isn't a "bad thing". It forces programmers to do the RIGHT thing, or their code blows up. I used to have to deal with this on Microport and other x86 processors. They had a "large model" which created multiple 64k (max) segments. If you played games with pointers (ie: trying to stuff a pointer into an int) you got fscked by this, and generated many core dumps :-) If you wrote syntatically CORRECT code, it worked. We seem to have forgotten that the means to enforce this kind of protection DOES exist in our current processors - but we don't want to use it, because it means we have to write correct code! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Mon, Jul 20, 1998 at 11:14:33AM -0600, Brett Glass wrote: > Waitaminnit. Intel installed, IN THE x86 CHIPS WE ARE NOW USING, special > hardware designed to guard against these exploits. The mechanisms > they designed are called "segments" and "call gates" (among other > things). And what do we do? We turn it off. In fact, Intel sees > so few people using these vital features that it doesn't bother > to speed them up in new CPU models, as they do other parts of > the chip. > > In short, the hackers who want slightly more convenient "flat" > address spaces have contributed in devastating ways to the problems > we have now. > > --Brett Glass > > At 03:29 PM 7/20/98 +0400, Alexandre Snarskii wrote: > > >On Sun, Jul 19, 1998 at 07:48:30PM -0600, Warner Losh wrote: > >> > >> 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. > > > >At huge computing price. Measured in seconds, spent by processor > >to perform needed computing. As for me, the cost of upgrade to > >computers, which will perform these computing is much less > >than the cost of every outage caused by remote exploit. > >Just my 2 cents. > >-- > >Alexandre Snarskii > >the source code is included > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message 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?19980720122652.35370>