export LD_LIBRARY_PATH in /etc/profile.d/* files

[rich () annexia org]

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