Hemantha Holla wrote:
> 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.
That causes it to be exported in the environment of $prog and it's children, but
not other processes started in the shell script.
> 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 ?
If you don't need to set it, the best solution would be to just remove
the shell script code to set it, and let any setting from the environment
pass through on it's own. This isn't an "attack", just preventing the
path you set from affecting other processes - if you don't set one, then
that's not a problem.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
