[478] in linux-security and linux-alert archive
Another possible problem with ld.so?
daemon@ATHENA.MIT.EDU (Marek Michalkiewicz)
Thu Nov 9 11:21:45 1995
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
To: linux-security@tarsier.cv.nrao.edu, linux-gcc@vger.rutgers.edu
Date: Thu, 9 Nov 1995 14:47:23 +0100 (MET)
This is probably not a big hole by itself, but I think it is worth
mentioning. It may, for example, cause security problems with setuid
wrapper programs which execute some other programs after setting the
real uid to the effective uid, and are not careful enough about the
environment.
ld.so-1.7.10 does the following when uid != euid:
/* sorry, Charlie, I can't let you do that */
if ((cp = getenv("LD_PRELOAD")))
*cp = '\0';
if ((cp = getenv("LD_ELF_PRELOAD")))
*cp = '\0';
if ((cp = getenv("LD_AOUT_PRELOAD")))
*cp = '\0';
... and so on with LD_LIBRARY_PATH, LD_ELF_LIBRARY_PATH, and
LD_AOUT_LIBRARY_PATH.
This removes these variables from the environment (replaces them
with empty strings). This looks very nice, but what happens if
you have these variables defined multiple times? getenv() can
only find one string, it will be removed, but the rest will still
be there.
Now, let's say this is a setuid root wrapper program which executes
some command as root after doing setuid(0). If LD_LIBRARY_PATH was
defined twice in the environment, it will still be defined (only one
string has been removed) and passed to the new program (which will
now run with uid == euid so ld.so won't remove dangerous environment
strings). Similar problem has been discovered in SunOS some time ago
(it has been discussed on bugtraq).
It sounds like we need to remove all occurences of LD_xxx etc., not
just one. Replacing "if" instructions with "while" loops should do
the trick.
Marek
