From owner-freebsd-security@FreeBSD.ORG Wed Mar 26 08:18:07 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 D653D37B40E; Wed, 26 Mar 2003 08:18:07 -0800 (PST) Received: from pilchuck.reedmedia.net (pilchuck.reedmedia.net [209.166.74.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0983A43F85; Wed, 26 Mar 2003 08:18:07 -0800 (PST) (envelope-from reed@reedmedia.net) Received: from reed by pilchuck.reedmedia.net with local-esmtp (Exim 3.12 #1 (Debian)) id 18yDbG-0006kW-00; Wed, 26 Mar 2003 08:18:02 -0800 Date: Wed, 26 Mar 2003 08:18:02 -0800 (PST) From: "Jeremy C. Reed" To: "Jacques A. Vidrine" In-Reply-To: <20030326140204.GC33671@madman.celabo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-15.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Mailman-Approved-At: Wed, 26 Mar 2003 14:53:17 -0800 cc: freebsd-security@FREEBSD.ORG 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 16:18:09 -0000 On Wed, 26 Mar 2003, Jacques A. Vidrine wrote: > 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.) That is why I was wondering if anyone knew what actually uses the functions that had security issues :) On Wed, 26 Mar 2003, Jacques A. Vidrine wrote: > > The recent XDR fixes the xdrmem_getlong_aligned(), > > xdrmem_putlong_aligned(), xdrmem_getlong_unaligned(), > > xdrmem_putlong_unaligned(), xdrmem_getbytes(), and/or xdrmem_putbytes() > > functions, but it is difficult to know what uses these (going backwards > > manually). > > You'll never find it starting with those :-) Rather, look for uses of > xdrmem_create. I understand. (I already couldn't find any of those functions used by anything else other than xdrmem_create.) That is my point: it is hard to tell what uses what. > Well, not _only_ for RPC, but certainly RPC is the big consumer. > Almost any RPC application will also be using an xdrmem stream. > Depending upon the data types marshalled through the stream, one of > the affected routines may be called. > > Other applications could also use XDR directly, such as to serialize > data for storage. I don't think this is very common. Thanks for the explanation. (Now to figure out what is actually effected.) > Have a look at Colin Percival's binary updates stuff. He believes he > has overcome these issues. I will look at it closer. (But I was told off-list that it didn't. Nevertheless, it would be nice to find a way to automate this.) > Also, one can pull out the `relevant' ELF sections, and compare those > for a pretty good picture. You could use objcopy. I've used libelf > to do the same. Thanks for the ideas. I will give these a try. I see libelf is a library for manipulating ELF -- is there a tool that uses it (like Solaris pvs(1))? Jeremy C. Reed http://bsd.reedmedia.net/