-----BEGIN PGP SIGNED MESSAGE-----

===========================================================================
              AUSCERT External Security Bulletin Redistribution
                             
               ESB-2000.045 -- Sendmail Security Announcement
              Unexpected and dangerous AIX 4.X linker behavior
                                14 March 2000

===========================================================================

Sendmail Consortium has released the following security advisory describing
a vulnerability in IBM's AIX 4.X linker behavior.  This vulnerability may
allow an intruder to influence which dynamic libraries are loaded by
affected programs. This may allow an intruder to remotely execute arbitrary
code with privileged access.

IBM have acknowledged the issue and are investigating the extent of
this vulnerability within AIX 4.X. IBM will release separate advisories
relating to any affected AIX 4.X programs as it finds them.

Sites using third-party software on AIX 4.X systems are advised to check
their programs and build environments with regards to this vulnerability.
Special attention is recommended for daemons which execute with
privileged access and setuid root programs.

- --------------------------BEGIN INCLUDED TEXT--------------------

- -----BEGIN PGP SIGNED MESSAGE-----

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.


			     Problem Statement
			     -----------------

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.


				Workaround
				----------

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

We have not attempted this and recommend sendmail users recompile using the
instructions below.


			    Sendmail Specifics
			    ------------------

sendmail users compiling on AIX can create one or more of the files
(depending on the version(s) of AIX in use):

   sendmail-8.10.0/devtools/Site/site.AIX.4.2.m4
   sendmail-8.10.0/devtools/Site/site.AIX.4.3.m4
   sendmail-8.10.0/devtools/Site/site.AIX.4.x.m4

with the contents:

define(`confLDOPTS', `-blibpath:/usr/lib:/lib')

to protect their sendmail compilation.  Users may have to add additional
paths if they use libraries in other (safe) system directories, such as
/usr/local/lib.  After create the site files, recompile and reinstall all
of the programs which accompany sendmail:

   cd sendmail-8.10.0
   rm -rf obj.AIX.*
   make

If anyone has additional information, including other platforms which may
have similar linker behavior, please send mail to
sendmail-security@sendmail.org as future releases of sendmail will include
protections against this problem.  A new version of sendmail will be
released as soon after feedback regarding this problem has been collected.


			      Vendor Response
			      ---------------

			      IBM Corporation
			      ---------------

The AIX version 4 linker has always documented the -blibpath option as a
mechanism for removing build environment dependencies from a runtime
environment.  Applications that gain privilege should always use this
option to remove library search paths that may not/should not exist on
customer machines.

The use of relative library paths is also 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.

We are currently investigating the potential Makefile errors in our
build environment and will release APARs as they are discovered.  These
and any other AIX security vulnerabilities can be reported to
security-alert@austin.ibm.com.

- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0 for non-commercial use
Charset: noconv

iQCVAwUBOM3fI8ApykAW9MzpAQFeOAP+NXF/EKI8pn6SDJh9OsAk6SyUDqfwP6Cz
IqCoMoQQqfdK4YV747g+SvsRLKuVQwnE1ImO3ApHgJVF5rOS8UYTsRp0Q1djGACB
uN/qrtihTY/OfoKhTM+EMgqqKgGeQymNppIVFIAMYw/mDm3ek7Gc89NKJuaK9tZp
G01xKp0QJU4=
=T0+l
- -----END PGP SIGNATURE-----

- --------------------------END INCLUDED TEXT--------------------

This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content.  The decision to use any or all of this information is
the responsibility of each user or organisation, and should be done so in
accordance with site policies and procedures.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the original authors to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

	http://www.auscert.org.au/Information/advisories.html

If you believe that your system has been compromised, contact AusCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).

Internet Email: auscert@auscert.org.au
Facsimile:	(07) 3365 7031
Telephone:	(07) 3365 4417 (International: +61 7 3365 4417)
		AusCERT personnel answer during Queensland business hours
		which are GMT+10:00 (AEST).
		On call after hours for emergencies.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key

iQCVAwUBONiY2Ch9+71yA2DNAQESigP/ULuZ/6krPH14zXldqBvo35yJj0qS+4fe
4M0mr53OqgTKRm7sfYzrQJ50ppBVau/844xHHShafUfDZ2V6D5RUhD9xhBFSYU/s
3jMEZPQ0O5uL5dDaDsTz2i7Eox4kF9yUcqR0TX3CXw0ZfQjsW9DaICWD3IN4Ws4K
PX1s8z4jaLE=
=MSYD
-----END PGP SIGNATURE-----