mailing list archives
Re: Smashing the Stack: prevention?
From: jrvalverde () SAMBA CNB UAM ES (J.R.Valverde)
Date: Tue, 29 Apr 1997 10:35:09 WET
Just one more way: replace ususal strcpy/sprintf/strcat
in libc to check stack integrity before exit, and generate
kill(SIGSEGV,getpid()) in case of violations.
That is a 'bad thing' from the performance point of view,
but not so bad (about 1% more time with stack
level 10); and that is not portable - because
stack checker must be written in assembler.
Once more I have to disagree. The str*cpy et al case
is but an instance of a broader case, and as such this is
a focalized "quick&dirty hack".
First an example: the str*cpy case is but an array
out of bounds error. There may be many others. What if an
application did read a series of numbers (say IP addresses)
into an array whithout correct bounds checking? I would just
correctly enter more and more numbers and easily overwrite
whatever I wanted with whatever arbitrary binary values with
Your proposed solution would just move into the system
some functionality that a language lacks, and which would be
better handled by a compiler. Again, it is just a matter of
using the appropriate tools (compiler, debugger, etc...). The
reason of being for C and/or assembler is to allow dirty tricks
and fast implementations at the cost of additional work for
the programmer. If the programmer shouldn't do that extra work
or if dirty tricks are not to be allowed, then a different
language must be used, at the cost of efficiency and freedom.
All in all, I don't think that compiler functionality
should be moved into the system unless you want a java- (or
taos-*) -like system (and again at the cost of some performance).
But then we are back to the problem of using the most suitable
tool/system for a given task.
Maybe you should consider using a different operating
* sorry, I'm in a bit of a hurry, and don't exactly remember now if
it was taos the other system I remember that run on a virtual
interpreter machine. Think it was. Will check later.
- Re: Smashing the Stack: prevention?, (continued)