Solar  Designer  posted  following.   There's  another  problem in (and the a.out linker, 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/ 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 #2 on Linux page of Security Bugware).  Here's how  to
    check for this problem:

        host:/lib# ls -l*
        -rwxr-xr-x   1 root     root      1861963 Mar 24  1997*
        -rwxr-xr-x   1 bin      bin       1849257 Aug 27 23:52*
        host:/lib# chmod 700
        host:/lib# ldd /bin/ls
       => /lib/ (0x119000)
        host:/lib# su user
        host:/lib$ ldd /bin/ls
       => /lib/ (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