OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Unexpected and dangerous AIX 4.X linker behavior
From: Dan Harkless (dan-bugtraqDILVISH.SPEED.NET)
Date: Wed Mar 15 2000 - 18:56:36 CST

Gregory Neil Shapiro <gshapiroSENDMAIL.ORG> writes:
> 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.

I just did some testing and the problem is not limited to IBM's native
linker. Executables linked using my copy of GNU ld:

    % /usr/local/bin/ld -v
    GNU ld version 2.9.1 (with BFD 2.9.1)

exhibit the same vulnerability. It would seem the GNU ld authors
intentionally emulated the harmful behavior of /usr/ccs/bin/ld.

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

Um, I don't believe -rpath is a gcc option. It's a GNU ld option, analagous
to IBM ld's -blibpath option.

> 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

If using gcc and GNU ld, that'd be:

    gcc -Wl,-rpath /usr/lib -Wl,-rpath /lib -Wl,-rpath /usr/local/lib

----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-bugtraqdilvish.speed.net | do not mention this private email
SpeedGate Communications, Inc. | address in Usenet posts. Thank you.