Date: Mon, 10 Feb 1997 22:04:47 -0800 (PST) From: Dmitry Kohmanyuk <dk@dog.farm.org> To: snar@lucky.net (Alexander Snarskii) Cc: freebsd-hackers@freebsd.org Subject: Re: Increasing overall security.... Message-ID: <199702110604.WAA14933@dog.farm.org>
next in thread | raw e-mail | index | archive | help
In article <199702091525.RAA05048@burka.carrier.kiev.ua> you wrote: > 'Why don't rewrite that functions to check the stack integrity > before return?' says Oleg Panaschenko sometimes ago, and after > some reflections i found that that is not so bad idea. Yes, we're > getting some overhead with using these functions rather than > with standard ones, but, as for me, this overhead is not so big > and a reason, that i can sleep without nightmares about another > stack overflow exploits is much important for me. that's very good idea. I don't understand the reasons from other people responding to this negatively. Having someone looking for holes is very good, indeed; but, having computer used for detecting possible security holes at runtime seems like a good idea for me... also, for anyone concerned with performance hits when using these patches: well, maybe the best thing would to have an option when building libraries and static binaries, so you can make your world with -DPARANOID_LIBC if you feel like it. (editing your make.conf or <bsd.*.mk> ) it's on the similar scale with phkmalloc's runtime checks - can be a good thing to stress-test existing programs while not necessary a good thing for everyone. This also puts a suggestion for adding syslog() or at least fprintf(stderr) into these mods... > IDEA NOTES: > There are two new functions: checkframe__(char* a,char* b), which > checks that we have no stack frames (generated by call _func) > in memory region [a,b], and insane__(char* function-name,char* buffer), > which are just performs kill(SIGSEGV,getpid()) (because program > will got this signal while 'ret' to junk address in stack anyway > but exploited) and after exit(1) (for cases like signal(SIG_SEGV,SIG_IGN) > :) ). And most functions, which can be used for stack exploiting, > patched to check the changed memory region to avoid stack violation. > These functions are: strcpy,strcat,sprintf ( well, 90% of such exploits > used it ), gets (historical reasons :) ) and memcpy (some things, like > scanf and so uses it). -- Don't take life too seriously. You'll never get out of it alive.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702110604.WAA14933>