>> 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.
Ok,thanks. I'll clarify how it affects the man-in-middle issue in
section 4.2
from my team and update ARC material.
> 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.
Sorry for being unclear - I was referring to the man-in-middle issue from
section 4.2 when I said 'attack' :
Firefox 3.5.x man-in-middle issue handling : /usr/bin/firefox will be a
script that calls /usr/lib/firefox/run-mozilla.sh which will then call
firefox-bin. /usr/bin/firefox and run-mozilla.sh scripts set a number of
environment variables. All the plugins are spawned by firefox-bin. So,
LD_LIBRARY_PATH environment variable will be set to
/usr/lib/gnome-private in run-mozilla.sh script to avoid linking/loading
of the plugins with libraries older/different versions of the new
libraries and they will always link to /usr/lib/gnome-private libraries.
Thanks
Hemantha
