From owner-freebsd-security Mon Jul 20 10:28:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA06082 for freebsd-security-outgoing; Mon, 20 Jul 1998 10:28:10 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06068 for ; Mon, 20 Jul 1998 10:28:02 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id MAA17706; Mon, 20 Jul 1998 12:26:53 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id MAA01421; Mon, 20 Jul 1998 12:26:52 -0500 (CDT) Message-ID: <19980720122652.35370@mcs.net> Date: Mon, 20 Jul 1998 12:26:52 -0500 From: Karl Denninger To: Brett Glass Cc: Alexandre Snarskii , Warner Losh , Archie Cobbs , security@FreeBSD.ORG Subject: Re: The 99,999-bug question: Why can you execute from the stack? 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199807201714.LAA19993@lariat.lariat.org>; from Brett Glass on Mon, Jul 20, 1998 at 11:14:33AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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