Tracing binaries statically linked against vulnerable libs

Simon L. Nielsen simon at FreeBSD.org
Sat Oct 14 05:23:58 PDT 2006


On 2006.10.14 08:11:56 -0400, Michael Johnson wrote:
> On 10/13/06, Kris Kennaway <kris at obsecurity.org> wrote:
> >On Fri, Oct 13, 2006 at 05:18:57PM +0400, Andrew Pantyukhin wrote:
> >> On 10/7/06, Kris Kennaway <kris at 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


More information about the freebsd-hackers mailing list