From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill C Riemers To: "Ronald F. Guilmette" Cc: freebsd-hackers@freebsd.org, gnu-gcc@gnu.org Subject: Re: Defending against buffer overflows. Date: Mon, 21 Feb 2000 07:24:00 -0000 Message-id: <38B1584A.3CF0E8FC@feynman.com> References: <12502.950912447@monkeys.com> X-SW-Source: 2000-02/msg00070.html "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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill C Riemers To: "Ronald F. Guilmette" Cc: freebsd-hackers@freebsd.org, gnu-gcc@gnu.org Subject: Re: Defending against buffer overflows. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <38B1584A.3CF0E8FC@feynman.com> References: <12502.950912447@monkeys.com> X-SW-Source: 2000-q1/msg00264.html Message-ID: <20000401000000.wnWd7G46kveS7K2jdYoWXy0bMo1Or2xS7XLjtMO1T1Q@z> "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