Date: Wed, 22 Jul 1998 01:31:20 +0400 From: Alexandre Snarskii <snar@paranoia.ru> To: Don Lewis <Don.Lewis@tsc.tdk.com>, Alexandre Snarskii <snar@paranoia.ru>, Warner Losh <imp@village.org>, Archie Cobbs <archie@whistle.com> Cc: Brett Glass <brett@lariat.org>, security@FreeBSD.ORG Subject: Re: The 99,999-bug question: Why can you execute from the stack? Message-ID: <19980722013120.32585@nevalink.ru> In-Reply-To: <199807202130.OAA27539@salsa.gv.tsc.tdk.com>; from Don Lewis on Mon, Jul 20, 1998 at 02:30:33PM -0700 References: <snar@paranoia.ru> <199807202130.OAA27539@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 20, 1998 at 02:30:33PM -0700, Don Lewis wrote: > On Jul 20, 3:29pm, Alexandre Snarskii wrote: > } Subject: Re: The 99,999-bug question: Why can you execute from the stack? > } On Sun, Jul 19, 1998 at 07:48:30PM -0600, Warner Losh wrote: > > } > 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. > > It may be worse than that. In a desparate attempt to track down a > bug in BIND, I recompiled it with the bounds checking version of > gcc. On a fairly zippy machine, it took about half an hour to load > a few zones with a total of a few hundred hosts. Under light query > load it was gobbling about 30% of the CPU. You got the named with _total_ bounds checking. With correct bounds checking only on some functions (strcpy/sprintf/strcat et al, which gets the 95% buffer overflows since Internet worm ) my named works just fine. > In the situations where I've used code compiled this way, it seems > to average about a factor of 20 more expensive in terms of CPU usage. Strange result. Program, which does nothig but 100.000 strcpy's works _six_ times slower with bounds checking, but not 20... -- Alexandre Snarskii the source code is included 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?19980722013120.32585>