From owner-freebsd-security Wed Jun 26 18:29:41 2002 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4619D37D5D9 for ; Wed, 26 Jun 2002 17:52:13 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g5R0qAw6019343; Wed, 26 Jun 2002 20:52:10 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 26 Jun 2002 20:52:10 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Brian Behlendorf Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:28.resolv In-Reply-To: <20020626152851.Q310-100000@yez.hyperreal.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 26 Jun 2002, Brian Behlendorf wrote: > On Wed, 26 Jun 2002, Robert Watson wrote: > > You will catch most applications simply by rebuilding libc and > > reinstalling. Unfortunately, some applications are statically linked, and > > they must be individually relinked against the new libc and reinstalled. > > Sorry for the newbie question here, but is there a way to > programmatically determine which binaries on a system static-linked > libc? I tried "nm" but that needs non-stripped executables... Well, there are a number of gradations of "dynamically" and "statically" linked, but from a practical perspective there are two ways to figure out how something is linked. First, look at the binary itself on an installed system, perhaps using the file command: curry:~/freebsd/src/bin> file /usr/bin/add* /usr/bin/addftinfo: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped /usr/bin/addr2line: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, stripped The other is to look in the FreeBSD source tree to see whether the binary is built with NOSHARED. For example: curry:~/freebsd/src> grep -i SHARED bin/Make* bin/Makefile.inc:NOSHARED?= YES Because of the recursive build infrastructure, using the first of these may be easiest if your source tree and system are already in sync. The other wrinkle is that not all statically linked binaries *use* the DNS calls, and only those that actually use the call really need to be reinstalled. You can use nm to inspect the binary and see if it does use any DNS calls, or if it relies on any calls that use DNS calls, but again, the simplist approach might just be to replace all of them to make sure you don't miss anything. Regardless of your approach for statis binaries, you will need to rebuilt the dynamic libc library from a fixed source tree to get all the dynamically linked applications. Also, run file on /usr/local/{bin,sbin} to make sure no ports installed statically that require updating. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message