Tracing binaries statically linked against vulnerable libs

[Michael Johnson]

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.

With that said I do see the point you're making and I do
agree if at all possible make a shared library.

Michael
>
> > I know Gentoo has this Prelink feature
> > (http://www.gentoo.org/doc/en/prelink-howto.xml) which
> > helps with performance, but looks like a hack.
> >
> > Anyway, maybe portmgr could issue some kind of a policy
> > about this. I.e. (1) use {build,run}_depends instead of lib_
> > when you depend on a port providing both shared and
> > static libraries, but link statically; (2) make an effort to
> > encourage dynamic linking - try to provide only shared
> > libs in new ports, remove unused static ones from old
> > ones, and so on.
>
> (1) is just a statement of correct behaviour, no need for a policy
> about it (it could be clarified in the porters handbook if needed).
> (2) could also be added to the porter's handbook as a recommendation-
> I don't think we need a formal proclamation of policy about it.
>
> Kris
>
> P.S. I can provide a list of static binaries in ports if anyone wants
> to work on fixing them.
>
>
>