From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 14 15:20:47 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4395D16A4C9 for ; Sat, 14 Oct 2006 15:20:47 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2F9443DCA for ; Sat, 14 Oct 2006 15:19:54 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so1318152nfc for ; Sat, 14 Oct 2006 08:19:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=D4qoGrqLKy7XfLKcq5gUS8e/gtS1YsSRKM+rEIMmGFLrAMFGDPigiOuH/k82ADV02zallt6wNiWcLv23JDH6bRVWh73jd55lV3mC2sk2NZ6zSGgCU/6ztFX2nsWPTZr4Ij9pW1KOvdi105ET4OU6ILUYZlTiNhvJbk7ujuorGvc= Received: by 10.78.203.13 with SMTP id a13mr5304000hug; Sat, 14 Oct 2006 08:19:52 -0700 (PDT) Received: by 10.78.167.16 with HTTP; Sat, 14 Oct 2006 08:19:52 -0700 (PDT) Message-ID: Date: Sat, 14 Oct 2006 19:19:52 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Simon L. Nielsen" In-Reply-To: <20061014122356.GD45953@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061006215902.GA21109@xor.obsecurity.org> <20061014003238.GA6341@xor.obsecurity.org> <20061014122356.GD45953@zaphod.nitro.dk> X-Google-Sender-Auth: 6291d378e7322082 Cc: Michael Johnson , hackers@freebsd.org, secteam@freebsd.org, Kris Kennaway Subject: Re: Tracing binaries statically linked against vulnerable libs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2006 15:20:47 -0000 On 10/14/06, Simon L. Nielsen wrote: > On 2006.10.14 08:11:56 -0400, Michael Johnson wrote: > > On 10/13/06, Kris Kennaway wrote: > > >On Fri, Oct 13, 2006 at 05:18:57PM +0400, Andrew Pantyukhin wrote: > > >> On 10/7/06, Kris Kennaway wrote: > > >> >On Fri, Oct 06, 2006 at 09:35:31AM +0400, Andrew Pantyukhin wrote: > > >> >> I wonder if there is a way to deal with statically linked binaries, > > >> >> which use vulnerable libraries. > > >> > > > >> >The best way is to track them down and force them all to link > > >> >dynamically; static linking is a PITA from a systems management point > > >> >of view :) > > >> > > >> Do you think we could do that without a serious impact on > > >> performance? > > > > > >In most of the cases I've looked at the statically linked binary is > > >not performance critical or otherwise necessary (the only exception I > > >saw is for some tripwire-like port whose name I forget, which is > > >statically linked as a security enhancement, to make it lease easily > > >subverted). Static linking can be made an OPTION if someone thinks > > >it's really necessary for a given port. > > > > Each of the ports listed in this thread are bad examples of > > finding static linked to ffmpeg. libxine, gstreamer-ffmpeg, and mplayer > > include ffmpeg in their source and don't link to multimedia/ffmpeg. > > Patching these ports to use a shared version of ffmpeg is pretty > > much out of the question since we would lose support from the > > authors. > > If ports include their own vulnerable version each port should be > marked vulnerable and fixed. We have already done this for zlib, > libtiff etc. in the past. Yes. The question is how to discover them without a dozen of full-time security officers (i.e. in a scriptable/automated way). > For ports which just links statically against a library from another > port, and therefor need to be recompiled after the library port is > updated I don't think they should be marked vulnerable in VuXML, but > it might be a good idea to bump the portrevision of the ports to force > a recompile (at least I don't see any better ways to do this). Why not mark them vulnerable? There are many people who upgrade _only_ vulnerable ports. We would deceive them if we just bumped portrevisions.