There's another problem in ld-linux.so (and the a.out linker ld.so, too):
it is possible to trick the linker into loading old version of a library
if several versions are installed. This means that if you have upgraded
your libc (or libdb, etc) after a security hole was discovered, updated
/etc/ld.so.cache with ldconfig, and made sure the new version is used,
it still might be possible for an attacker to force a setuid binary into
using your old vulnerable version of the library, if you haven't removed
it from the directories scanned by ldconfig.
The problem is that ldconfig adds all versions of a library into the cache,
and the linker itself doesn't give up if an error occurs. Normally the
latest version is listed first, and it's the only one used. However, we
can consume up the resources, so that the linker fails to load the latest
version, and then free some resources before it tries to load an older one.
This is similar to the stuff Rafal Wojtczuk was explaining here recently
(actually, his post reminded me of this problem).
Here's how to check for this problem:
host:/lib# ls -l libc.so.5.4.*
-rwxr-xr-x 1 root root 1861963 Mar 24 1997 libc.so.5.4.23*
-rwxr-xr-x 1 bin bin 1849257 Aug 27 23:52 libc.so.5.4.38*
host:/lib# chmod 700 libc.so.5.4.38
host:/lib# ldd /bin/ls
libc.so.5 => /lib/libc.so.5.4.38 (0x119000)
host:/lib# su user
host:/lib$ ldd /bin/ls
libc.so.5 => /lib/libc.so.5.4.23 (0x119000)
The obvious fix would be to remove (chmod 0 is enough, chmod 700 isn't) all
old versions after upgrading. The real fix would be either to patch the
linker so it gives up on some errors (probably check for errno != ENOENT),
or change the way shared library packages install themselves, in all Linux
distributions that are affected.
Signed,
Solar Designer