Tracing binaries statically linked against vulnerable libs

[Andrew Pantyukhin]

On 10/14/06, Simon L. Nielsen <simon at freebsd.org> wrote:
> 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.

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.