Alan Coopersmith wrote:
>
> Hemantha Holla wrote:
>> Alan Coopersmith wrote:
>>>  (though you need to be cleaning
>>> either LD_LIBRARY_PATH variant from the environment you use to
>>> fork/exec()
>>> other processes, so you don't break existing gnome apps if you call them
>>> as external file viewer helpers).
>> Since this env variable will be only set, instead of being exported, any
>> spawned processes will not be poisoned with the private libraries.
>
> If it's not exported, it won't even affect the Firefox binary, so that
> doesn't make sense.

I am sorry; I misunderstood launching Firefox like this
  LD_LIBRARY_PATH_32=/usr/lib/gnome-private/lib "$prog" ${1+"$@"}
to mean that LD_LIBRARY_PATH_32 is only set and not exported.

Actually LD_LIBRARY_PATH* needn't be set to run Firefox. Since RUNPATH
is set to /usr/lib/gnome-private/lib while building Firefox and the
newer GNOME components, Firefox will pick up the new versions even
without setting LD_LIBRARY_PATH.

So instead of setting LD_LIBRARY_PATH, will unsetting it if user has
already set it, be enough to prevent this attack ? In this case (of
unsetting LD_LIBRARY_PATH), when plugins linked with older library
versions in /usr/lib are loaded (e.g. flash player plugin), there will
be 2 versions of the same library in memory.

Setting LD_LIBRARY_PATH and then clearing it when launching external
applications will need some modifications to Firefox code and none of us
in the team have looked into that yet.

>
>>> The following list seem like things needed to build firefox, but which
>>> don't need to be shipped to users of firefox - is there some reason
>>> these are needed, or is it just an artifact of the spec-files build
>>> system?  (Though it would seem easy enough to just not deliver the
>>> -devel packages for private components to the WOS.)
>> Some other teams have requested availability of some of the newer
>> libraries through contracts. These files will allow those teams to link
>> to the newer versions easily. If there is some other formal way in which
>> these can be made available to those teams, there is no need to ship the
>> -devel packages.
>
> You can deliver the -devel packages to those teams without delivering them
> to all customers, or you can deliver them to the WOS and accept that
> customers may see them and try using them.   (The -private in the directory
> name should be a strong clue that they shouldn't expect support for them.)

We'll deliver them to WOS. As you pointed out, while customers are free 
to use
them, they can't expect support.


Reply via email to