Date: Sun, 19 Jul 1998 03:58:28 +0400 From: Alexandre Snarskii <snar@paranoia.ru> To: freebsd-security@FreeBSD.ORG Subject: libparanoia announce. Message-ID: <19980719035828.63056@nevalink.ru>
next in thread | raw e-mail | index | archive | help
"I do not believe the code". Theo deRaadt, in some bugtrack posting Hi! That is just to notify subscribers of freebsd-security that old[*] idea of "secure wrapping" some functions, incorect usage of ones comes to security problems with buffer owerflows, had redesigned and published at ftp://ftp.lexa.ru/pub/domestic/snar/libparanoia.tgz That tarball contains modified sources of /usr/src/lib/libc/i386/string/strcpy.S /usr/src/lib/libc/i386/string/strcat.S /usr/src/lib/libc/stdio/gets.c /usr/src/lib/libc/stdio/vfprintf.c /usr/src/lib/libc/stdio/vfscanf.c , all the modifications - is calls to handwritten functions enter_violation right after entering the function and to exit_violation just before return. The purpose of enter_violation is to save last 10 stack frames ( means saved BP and IP registers ) from program stack into internal table, and purpose of exit_violation is to check, is these frames still the same ( i.e. no stack modifications made by some of these functions ), and, in case of corrupted stack performs logging to syslog and kill(SIGSEGV,getpid()) - because, in the best case we will got the same ( or SIGBUS ) signal on RET with incorrect saved IP , or, in worst case, IP will point to exec("/bin/sh")... That code can be used in two ways: a) you just making standalone libparanoia.(a|so) and linknig all the programs, which you want to secure that way, with one. b) you can use included copy-to-libc script to modify sources of your libc ( about all program will link libc.so at startup ). Note: you need installed sources of libc in any case. [*] You can find old discussion on that topic, searching freebsd-hackers with Subject: increasing overarll security. PS: of course, these functions works a little slower. ( Test, contained just 100000 strcpy's works six times slower. But, in "real life" there is no performance hit. PPS: that is not a panacea. Any problems with bad protocols/algorhytms still can cause security violations. More than, buffer overflows still possible with bad usage of fgets, for example. But it covers about 95% of known stack overflow attacks since Morrison's Worm to now. -- Alexandre Snarskii the source code is included To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980719035828.63056>