what actually uses xdr_mem.c?

[Bruce Evans]

On Wed, 26 Mar 2003, D J Hawkey Jr wrote:

> On Mar 27, at 04:22 PM, Bruce Evans wrote:
> >
> > On Wed, 26 Mar 2003, Uros Juvan wrote:
> >
> > > Idea is cool, but it just won't work on staticaly linked files, you can
> > > test this with:
> > >
> > > # readelf -a /bin/ls
> > >
> > > for example :(
> > ...
> > This isn't so obvious:
> >
> > %%%
> > Script started on Thu Mar 27 16:07:33 2003
> > ttyp0:bde at besplex:/tmp> strings -a /bin/ls | grep xdr_mem
> > $FreeBSD: src/lib/libc/xdr/xdr_mem.c,v 1.11 2002/03/22 21:53:26 obrien Exp $
> > ttyp0:bde at besplex:/tmp> exit
> >
> > Script done on Thu Mar 27 16:07:44 2003
> > %%%
> > ...
>
> OK, I now have to take this a little off-topic, and ask the following:
>
> Given that it's improbable, if not nearly impossible, to discover what
> statically-linked binaries may be involved with any vulnerability, isn't

This isn't given.  It is very easy to see xdr_mem.c in static binaries
in -current (see above).  If there were no id string, then is still easy
to see what is in static binaries if you don't strip them.  I install them
stripped but keep the originals in /usr/obj.

> it reasonable to ask if the benefits of statically-linked binaries aren't
> outweighed by the [security] drawbacks?

The only security drawbacks with statically-linked binaries are that you
can't fix security bugs for multiple programs by installing 1 new library.
This is also a security drawforward - installing 1 new library with a
security bug gives security bugs in multiple programs.

Bruce