Date: Mon, 21 Feb 2000 10:22:50 -0500 From: Bill C Riemers <bcr@feynman.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: freebsd-hackers@freebsd.org, gnu-gcc@gnu.org Subject: Re: Defending against buffer overflows. Message-ID: <38B1584A.3CF0E8FC@feynman.com> References: <12502.950912447@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38B1584A.3CF0E8FC>