Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Oct 2006 20:32:38 -0400
From:      Kris Kennaway <kris@obsecurity.org>
To:        Andrew Pantyukhin <infofarmer@FreeBSD.org>
Cc:        hackers@freebsd.org, secteam@freebsd.org, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: Tracing binaries statically linked against vulnerable libs
Message-ID:  <20061014003238.GA6341@xor.obsecurity.org>
In-Reply-To: <cb5206420610130618ycb0a14ev90dbcebdbf6b6316@mail.gmail.com>
References:  <cb5206420610052235t78033639vaa90429f07581078@mail.gmail.com> <20061006215902.GA21109@xor.obsecurity.org> <cb5206420610130618ycb0a14ev90dbcebdbf6b6316@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 :)
>=20
> 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.

> 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.
>=20
> 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.

--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFMDAlWry0BWjoQKURAln6AKCUOVI/zR2GbYsg7DIs5sPCd+MOUQCgoabX
Y2bvuWGudlnKpR3pYTHC+xI=
=sgqC
-----END PGP SIGNATURE-----

--ZGiS0Q5IWpPtfppv--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061014003238.GA6341>