modifing libc to discover gets()/sprintf() calls

[csh () VIEWGRAPHICS COM (Chris Sheldon)]

I've been following all the buffer overflows which have been posted
to bugtraq (loved the solaris gethostbyname() one), and I've also
tried to keep up with the patches, etc...

I was thinking about this last night and it occurred to me that
it would be of great benefit to know where the lib calls which
are causing these problems are. The two libc calls I've noticed
being exploited so far are gets() and sprintf().

(to give credit where.. etc): A while ago I wrote some Q&D c-code
on a freebsd box (2.1.0, I think) and used gets(). FreeBSD then
complained loudly about this fact with (I guess) a printf in the
the actual libc code. Something like "gets() is insecure! use fgets()".

My point to all this babble is, if (actually can) I dumped out the
libc.a file, replaced the gets.o and the sprintf.o (assuming those
are the correct files to modify) with some code from something
like FreeBSD or Linux (again, assuming that it was compatible *gasp*)
and added in a printf statement (or even better, a call to syslog())
to say "Hey, gets() is being used in this program", then I could determine
over time which programs are using insecure library calls. From there
it could be established which programs are either suid root or running
with root privs (like from inetd) and could be dealt with from there.

Of course, not every gets() or sprintf() call can be exploited, but
I'd rather know if some root priv'ed binary has one of these puppies.

The only big problem I is that any difference between the libc.a and
the running libc.so shared library would become painfully obvious
after creating and installing the new shared library with the
printf modifications.

I'm no library hacker, so is this even a doable task??

--
Chris Sheldon
csh () viewgraphics com
Unix Sysadmin / Net Admin