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 ABI invalid 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 libraries?
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 themselves known?
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 LD_LIBRARY_PATH altogether?
Bug 102287 seems to incorporate the fix for this issue by using rpath instead. *** This bug has been marked as a duplicate of 102287 ***
close as duplicate