COMMAND

    linker

SYSTEMS AFFECTED

    AIX 4.x

PROBLEM

    Valdis Kletnieks of Virginia Tech alerted the Sendmail  Consortium
    to  a  potentially  dangerous  side-effect  of the AIX 4.X linker.
    Unlike most other linkers, the AIX linker uses the paths specified
    at compile time  for the program's  shared library search  path at
    run  time.   Therefore,  AIX  compilations  which  use the -L flag
    with the AIX linker must use extra precautions to prevent security
    problems.

    We'll use  sendmail as  an example,  but this  is not  specific to
    sendmail; for example, the problem occurs with default compiles of
    ssh  (another  setuid  root  program),  the  Apache  utilities and
    wu-ftpd (and almost certainly others).  Also, binaries which  ship
    with AIX 4.3 have this problem.  For example, /usr/bin/imnsecd,  a
    setgid  program,  looks  for  shared  libraries  in  the   current
    directory  ('.')  before  checking  system  library   directories.
    /usr/sbin/db_file.dhcpo, /usr/sbin/dhcpsd,/usr/sbin/template.dhcpo
    also  all  look  in  the  current  directory  before  the  library
    directories.

    For our example, sendmail 8.10.0 comes with utility libraries.   A
    typical compile of sendmail on AIX would look like:

        ...
        /usr/bin/xlc -o sendmail -L../libsmutil main.o alias.o ... util.o
           version.o -lsmutil -lbind -ldbm
        ...

    A   binary   compiled   in    this   way   will   staticly    link
    ../libsmutil/libsmutil.a as expected.  But the -L flag also causes
    AIX to look in '../libsmutil' for shared libraries such as libc at
    run time even though it was  only used to link the static  library
    ../libsmutil/libsmutil.a.

    Most other systems do not use paths specified using the -L  option
    into the runtime search path.   For example, on Solaris you  would
    use -R for this, for gcc you would use -rpath, and so forth,  thus
    avoiding this problem.  (However,  gcc on SunOS 4 _does_  have the
    problem if  you don't  use -rpath,  at least  according to the man
    page)

    Since sendmail is  a setuid root  binary, this linker  behavior is
    even more dangerous.  However,  it is important to note  that this
    behavior can be used for  attacks on non-setuid binaries as  well.
    It is also  important to note  that providing the  fully qualified
    path to the compile-time library directories also present  dangers
    and the problem is not limited to relative paths.

    This  problem  affects  any  programs  which  link  with libraries
    outside of the standard library location paths (i.e., those  which
    use  -L  during  its  linking   phase).   Such  programs  can   be
    identified using AIX's 'dump' command:

        dump -H program

    The  output  will  include  the  library  path in the "Import File
    Strings" section:

                                ***Import File Strings***
        INDEX  PATH                          BASE                MEMBER
        0      .:/usr/lib:/lib
        1                                    libc.a              shr.o

    Programs should be checked for relative paths and unsafe  absolute
    paths.

SOLUTION

    Programs  in  this  situation  should  begin using the '-blibpath'
    option when using  the AIX linker.   This option states  that only
    the specified library directories should  be used at run time  for
    library paths.  For example:

        /usr/bin/xlc -blibpath:/usr/lib:/lib:/usr/local/lib

    Note that the xlc man page also indicates the environment variable
    LIBPATH is consulted for library paths.  Although this environment
    variable is not used if the  binary is setuid root, this may  also
    be  a  potential  problem.   Therefore,  it  is  recommended  that
    programs do  not use  the default  path and  always specify a path
    using the -blibpath option.

    According to IBM, existing executables can be relinked with a  new
    library path  even if  the source  or .o  files are not available.
    IBM has provided the following example:

        # cd /usr/sbin
        # cp dhcpsd dhcpsd.orig
        # chmod 0 dhcpsd.orig
        # ld -blibpath:/usr/lib:/lib -lc_r -lpthreads -lbsd -lpsa -ldl -lsrc -o dhcpsd.ld dhcpsd
        # mv dhcpsd.ld dhcpsd
        # chmod 554 dhcpsd

    The ld "-l" arguments are taken from the output of "dump -Hv":

        # dump -Hv dhcpsd
        [snip Loader Section lines]
                               ***Import File Strings***
        INDEX  PATH                          BASE                MEMBER
        0      .:/usr/sbin/:/build/export/power/usr/lib:/build/export/power/usr/ccs/lib:/usr/lib:/lib
        1                                    libc_r.a            shr.o
        2                                    libpthreads.a       shr_comm.o
        3                                    libpthreads.a       shr_xpg5.o
        4                                    libbsd.a            shr.o
        5                                    libpsa.a            shr.o
        6                                    libdl.a             shr.o
        7                                    libsrc.a            shr.o

    The use of  relative library paths  is highly discouraged.   While
    they can be  useful, the -blibpath  option should also  be used to
    not only avoid these types  of security issues, but to  remove the
    possibility of finding (or not finding at all) the wrong  relative
    directory, since relative paths at runtime will be based upon  the
    current working directory.