-----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-----