what actually uses xdr_mem.c?

[D J Hawkey Jr]

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 :(
> >
> > I don't think there is 100% way of telling whether staticaly linked file
> > is linked against vulnerable xdr_mem.o, especially because obviously
> > rcsid string is undefined in source file.
> 
> 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
> %%%
> 
> (strings -a shows a few other interesting strings and lots of bloat.)
> 
> xdr_mem.c has always had some sort of id string, but putting the string
> in the object file was broken for many years by putting the rcsid in
> the LIBC_SCCS section and then renaming LIBC_SCCS to LIBC_RCS in the
> Makefile without adjusting any source files that had ids.  This was fixed
> relatively recently in -current but is still broken in RELENG_4.

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
it reasonable to ask if the benefits of statically-linked binaries aren't
outweighed by the [security] drawbacks?

Granted, a "no static binaries" policy wouldn't cover things outside of
any given distribution, but at that point, the vendor is absolved.

> Bruce

Should this move on over to freebsd-hackers@ ?
Dave

-- 
  ______________________                         ______________________
  \__________________   \    D. J. HAWKEY JR.   /   __________________/
     \________________/\     hawkeyd at visi.com    /\________________/
                      http://www.visi.com/~hawkeyd/