Re: Unexpected and dangerous AIX 4.X linker behavior

[dan-bugtraq () DILVISH SPEED NET (Dan Harkless)]

Gregory Neil Shapiro <gshapiro () SENDMAIL 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-bugtraq () dilvish speed net  | do not mention this private email
SpeedGate Communications, Inc. | address in Usenet posts.  Thank you.