Date: Sat, 14 Oct 2006 14:23:57 +0200 From: "Simon L. Nielsen" <simon@FreeBSD.org> To: Michael Johnson <ahze@ahze.net> Cc: hackers@freebsd.org, secteam@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: Tracing binaries statically linked against vulnerable libs Message-ID: <20061014122356.GD45953@zaphod.nitro.dk> In-Reply-To: <b2203fed0610140511g66dd0c91xe1bc0a006b57337c@mail.gmail.com> References: <cb5206420610052235t78033639vaa90429f07581078@mail.gmail.com> <20061006215902.GA21109@xor.obsecurity.org> <cb5206420610130618ycb0a14ev90dbcebdbf6b6316@mail.gmail.com> <20061014003238.GA6341@xor.obsecurity.org> <b2203fed0610140511g66dd0c91xe1bc0a006b57337c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006.10.14 08:11:56 -0400, Michael Johnson wrote: > On 10/13/06, Kris Kennaway <kris@obsecurity.org> wrote: > >On Fri, Oct 13, 2006 at 05:18:57PM +0400, Andrew Pantyukhin wrote: > >> On 10/7/06, Kris Kennaway <kris@obsecurity.org> 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. 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). -- Simon L. Nielsen FreeBSD Security Team
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061014122356.GD45953>