COMMAND

	export LD_LIBRARY_PATH  in  /etc/profile.d/*  files  allows  local  root
	exploit

SYSTEMS AFFECTED

	Oracle.sh for instance

PROBLEM

	Richard Jones [http://www.annexia.org/] says :
	
	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.
	

SOLUTION

	Matt [mlh@zip.com.au] suggests :
	
	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_PATH}:}$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