COMMAND
ld-linux.so
SYSTEMS AFFECTED
Linux
PROBLEM
Solar Designer posted following. 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 recently (see
ld-linux.so #2 on Linux page of Security Bugware). 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)
SOLUTION
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.