Defending against buffer overflows.

Defending against buffer overflows.

[Ronald F. Guilmette]

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?

Re: Defending against buffer overflows.

[Bill C Riemers]

"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

Re: Defending against buffer overflows.

[Bill C Riemers]

"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

Defending against buffer overflows.

[Ronald F. Guilmette]

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?