Date: Wed, 26 Mar 2003 08:10:24 -0600 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: D J Hawkey Jr <hawkeyd@visi.com> Cc: security at FreeBSD <freebsd-security@freebsd.org> Subject: Re: what actually uses xdr_mem.c? Message-ID: <20030326141024.GD33671@madman.celabo.org> In-Reply-To: <20030326061041.A17052@sheol.localdomain> References: <Pine.LNX.4.43.0303252144400.21019-100000@pilchuck.reedmedia.net> <20030326102057.GC657@zi025.glhnet.mhn.de> <20030326061041.A17052@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 26, 2003 at 06:10:41AM -0600, D J Hawkey Jr wrote:
> Actually, I _would_ check the binaries. Scanning /usr/src doesn't cover
> anything installed via the ports collection (/usr/ports), from other
> sources, or "home-grown" software.
>
> A week or so ago, I posted a command that scans the binaries:
>
> find $DIR -type f \
> |xargs readelf -a 2>/dev/null \
> |awk '/^File:/ { name = $2; printed = 0; } \
> /XDR|xdr/ { if (!printed) { print name; printed = 1; } }' \
> |xargs ldd 2>/dev/null
>
> If it reports a pathed file without listing any shared libraries, then
> it is statically-linked.
>
> I can't say this is the definitive answer, but it worked in a controlled
> environment (i.e., known binaries), as well as a live system. You can
> break down it's components to see what each pipe does.
This approach won't work for static binaries (which is what the poster
was inquiring about).
It also will fail you in this case. Since (most) affected binaries do
not call xdrmem_* directly, those names will not appear in the
binaries' symbol tables. (Although related names might, which may or
may not be enough for you to go on.)
Cheers,
--
Jacques A. Vidrine <nectar@celabo.org> http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030326141024.GD33671>