From owner-freebsd-hackers Mon Feb 21 7:23:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by hub.freebsd.org (Postfix) with ESMTP id D997237BD85 for ; Mon, 21 Feb 2000 07:23:17 -0800 (PST) (envelope-from bcr@feynman.com) Received: from hoccson.ho.att.com ([135.16.2.30]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA02813; Mon, 21 Feb 2000 10:22:52 -0500 (EST) Received: from babel.lz.att.com by hoccson.ho.att.com (8.9.1b+Sun/ATTEMS-1.4.1 sol2) id KAA10980; Mon, 21 Feb 2000 10:33:19 -0500 (EST) Received: from feynman.com (marsian [135.25.14.216]) by babel.lz.att.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA14031; Mon, 21 Feb 2000 10:22:52 -0500 (EST) Message-ID: <38B1584A.3CF0E8FC@feynman.com> Date: Mon, 21 Feb 2000 10:22:50 -0500 From: Bill C Riemers Reply-To: bcr@babel.lz.att.com Organization: AT&T Labs X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Ronald F. Guilmette" Cc: freebsd-hackers@freebsd.org, gnu-gcc@gnu.org Subject: Re: Defending against buffer overflows. References: <12502.950912447@monkeys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Ronald F. Guilmette" wrote: > > My attention has just been called to: > > http://immunix.org/StackGuard/mechanism.html > > Given all of the buffer overrun vulnerabilities that have been found in > various network daemons over time, this seems like a worthwhile sort of > technique to apply when compiling, in particular, network daemons and/or > servers. > > I don't entirely agree with this fellow's approach however. I think that > the ``canary'' word should be located at the bottom end of the current > stack frame, i.e. in a place where no buffer overrun could possibly clobber > it. > > Seems to me that this would be a nice and useful little enhancement for gcc. > I wouldn't mind having something like a -fbuffer-overrun-checks option for > gcc, and I would definitely use it when compiling network daemons. > > Anybody else got an opinion? Most tools like, electric fens, purify, ... Do the same type of trick. It does slightly change the behavior of the code, so some bugs that appear without doing such a trick won't appear with it, and of course visa versa. The most significant effect is the changes as to when 'really' will not be able to grow the buffer... Overall, I think it is a good idea. It definitely should not be done behind a user's back, but a compiler option to enable it as part of debugging is probably a good idea. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message