Date: Tue, 14 Mar 2000 12:12:05 -0800
From: Gregory Neil Shapiro <gshapiro@SENDMAIL.ORG.>
To: [email protected]Subject: Unexpected and dangerous AIX 4.X linker behavior
-----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
[email protected] 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
[email protected].
-----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-----
