[Linux-Biella] [Fwd: export LD_LIBRARY_PATH in /etc/profile.d/* files]

[Paul TT]

su bugtraq hanno postato questa mail...
secondo voi e' effettivamente un problema di sicurezza?!?
nel caso io ho modificato cmq nel profile cosi':
export 
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+${LD_LIBRARY_PATH}:}$HOME/lib:/usr/local/lib
e altre lib se ce ne vanno...
cosi' appende solo se deve...


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