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

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

On Tue, Dec 17, 2002 at 06:51:00PM +0000, rich@annexia.org wrote:
> 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

[ ... ]


> 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.

But isn't a . in LD_LIBRARY_PATH the same as an empty entry.
Or anyway, just as insecure?

What the original script should do is append to LD_LIBRARY_PATH
only if it is already defined. It's quite a common mistake I fear.

Scripts should do:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+${LD_LIBRARY_PA TH}:}$ORACLE_HOME/lib

Which is the same as

if [ -n "$LD_LIBRARY_PATH" ]
then
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:$ORACLE_HOME/lib
else
LD_LIBRARY_PATH=$ORACLE_HOME/lib
fi

Even Oracle's own oraenv script gets it wrong, but at least it
leaves the empty entry at the end.

Matt

> > 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.
>
> But isn't a . in LD_LIBRARY_PATH the same as an empty entry.
> Or anyway, just as insecure?

They mean the same but one is less likely to apear in the variable by
accident as happens in this case.

> What the original script should do is append to LD_LIBRARY_PATH
> only if it is already defined. It's quite a common mistake I fear.

Agree, but with the system-wide ignoring of blank LD_LIBRARY_PATH entries
you have some fault-tolerance against wrongheaded packages.


--
################################################## ############
# Antonomasia ant notatla.demon.co.uk #
# See http://www.notatla.demon.co.uk/ #
################################################## ############