From owner-freebsd-security@FreeBSD.ORG Wed Mar 26 06:10:25 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C215837B405 for ; Wed, 26 Mar 2003 06:10:25 -0800 (PST) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E56943F85 for ; Wed, 26 Mar 2003 06:10:25 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 81BF19A; Wed, 26 Mar 2003 08:10:24 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 6C68D78C43; Wed, 26 Mar 2003 08:10:24 -0600 (CST) Date: Wed, 26 Mar 2003 08:10:24 -0600 From: "Jacques A. Vidrine" To: D J Hawkey Jr Message-ID: <20030326141024.GD33671@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , D J Hawkey Jr , Simon Barner , "Jeremy C. Reed" , security at FreeBSD References: <20030326102057.GC657@zi025.glhnet.mhn.de> <20030326061041.A17052@sheol.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030326061041.A17052@sheol.localdomain> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 X-Spam-Status: No, hits=-31.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: "Jeremy C. Reed" cc: security at FreeBSD Subject: Re: what actually uses xdr_mem.c? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 14:10:26 -0000 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 http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se