hades /home/dwmw2 $ file libnsl.so.1
libnsl.so.1: ELF 32-bit LSB shared object, ARM, version 1 (ARM), stripped
hades /home/dwmw2 $ oowriter
Starting OpenOffice.org ...
/usr/sbin/lpc: error while loading shared libraries: libnsl.so.1: ELF file OS
lpc: error while loading shared libraries: libnsl.so.1: ELF file OS ABI invalid
lpstat: error while loading shared libraries: libnsl.so.1: ELF file OS ABI invalid
Something is setting LD_LIBRARY_PATH to
/usr/lib/openoffice/program/local:/usr/lib/openoffice/program: (note the final
colon at the end which makes the current directory get searched).
This is probably exploitable.
OOI, why aren't these directories in the rpath of the executables which need
them? That would also allow prelinking to work.
Blizzard kept mentioning how evil rpath was :) Seriously though, the code that
re-did the rpath for _every_ library in the 1.0.x specfile (all 100+ of them)
was really evil and I haven't merged it back into 1.1 yet. Will do.
Created attachment 106019 [details]
don't allow trailing :
soffice.sh (which ends up as soffice) is the culprit for the trailing :.
Attached is a patch to fix it for 1.1.X
Upstream for 2.0 is http://www.openoffice.org/issues/show_bug.cgi?id=36463
Are we sure this works and won't break by not being able to find
Yeah. The current case does not actually explictly add the cwd to
LD_LIBRARY_PATH. Consider the case of someone right now with a
LD_LIBRARY_PATH set to e.g. /tmp/uselessfoobar before they run oofice,
in this scenario it ends up as "correctooodirs:/tmp/uselessfoobar".
i.e. without the cwd being added to the LD_LIBRARY_PATH, cwd is only
getting added as a side effect when there happens to be no initial
LD_LIBRARY_PATH. Anyway I tried it after making the change and it
worked, as did the edge case of deleting ~/.rhopenoffice1.1 and
running ooffice which runs setup and running it then.
But shouldn't the OOo executables and library have an explicit runpath
anyway, in order to ensure that prelinking actually works?
Would it be better to refrain from setting LD_LIBRARY_PATH altogether,
so that any subtle bugs in the setting of the runpath actually make
Methinks rpath is a seperate issue, logged by yourself as #122113# :-)
(prelink as #102287#). The task at hand here is just any potential
exploitablity arising out of a LD_LIBRARY_PATH that can include cwd
True. I was thinking holistically -- why not just stop setting
Bug 102287 seems to incorporate the fix for this issue by using rpath
*** This bug has been marked as a duplicate of 102287 ***
close as duplicate