X-RDate: Wed, 11 Feb 1998 15:48:47 +0500 (ESK)
Date: Tue, 10 Feb 1998 13:30:47 -0600
From: Aleph One <aleph1@dfw.dfw.net>
To: BUGTRAQ@NETSPACE.ORG
Subject: ld confusion
There is been some confusion over the whole LD_PRELOAD thread. Hopefully
this will clear things up.
The are two dynamic linkers used by the Linux community, the old ld
(ld-linux.so.1) maintained by David Engle <david@sw.ods.com> and the newer
ld part of the GNU libc (aka glibc aka libc6).
ld-linux used to not ignore LD_PRELOAD and LD_LIBRARY_PATH for setuid/gid
programs. This changed in version 1.6.7 and was further refined in
1.7.6 and 1.7.11. That version changed ld-linux.so to delete all
variations of LD_PRELOAD and LD_LIBRARY_PATH for set[ug]id programs.
This changed in version 1.9.0. That version changed ld-linux.so to load
the libraries listed in LD_PRELOAD for setuid/gid programs as long as they
could be loaded securely. "Securely" means that the libraries in
LD_PRELOAD must not contain '/' in them and therefore will be loaded from
the configured library directories (/lib, /usr/lib, etc) and not from a
user supplied one.
The GNU dynamic linker in a similar move ignored LD_PRELOAD for
setuid/guid binaries. Ulrich Drepper changed it to allow loading
"securely" libraries from LD_PRELOAD for setuid/gid programs on Jan 20,
1997 (version???).
Solaris 2 has the same behavior of loading "securely" libraries listed on
LD_PRELOAD for setuid/gid binaries. I would expect many other operating
systems to do the same.
This system is vulnerable to an attacker preloading an old library with
known vulnerabilities that has not been deleted from the library directory
while running a setuid/gid program. The correct solution is to ignore
LD_PRELOAD for setuid/gid program and use /etc/ld.so.preload for global
preload libraries. ld.so.preload was introduced in version 1.8.0 of
ld-linux and is part of almost every other ld.
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
