Re: LD_PRELOAD potential problems

[james () VANEYCK GII GETTY EDU (James Lockwood)]

On Tue, 11 May 1999, David F. Skoll wrote:

> I recently ran across a piece of software which depended upon knowing
> the time reasonably accurately.  By replacing the time(2) UNIX system
> call with my own function, I was able to fool the program and get it
> to misbehave, without the inconvenience of actually changing the system
> time or even requiring root privileges.
>
> If you are writing programs which depend on C library functions or
> UNIX system calls for secure operation, please distribute only
> statically-linked versions, as the effort to fool statically-linked
> binaries is a lot higher than a simple LD_PRELOAD spoof.

I would hardly call 30 seconds with adb or gdb "a lot higher".  Static
linking is bad for many reasons, one of the chief being that if bugs are
found in the libraries you are using there is no way to fix the
executable.  Static linking also wastes memory, and many Unices are
starting to deprecate static linking of system libraries (Solaris is a
good example).

If you must have your program run in an unaltered state, then ask that it
be installed setuid nobody (for example) and have it drop uid/gid privs in
the first two lines of code.  LD_PRELOAD (and LD_LIBRARY_PATH, for that
matter) are not honored on setuid executables.

If you are distributing time-limited crippleware, then nothing will help
you.  Those who want to bypass it will, but most will not.  There is no
way around this, as long as the user is downloading and executing your
code under her control she will be able to modify it.

Normally I wouldn't consider this a worthwhile discussion for BUGTRAQ, but
I think that the point must be made that static linking prevents library
fixes from being propagated to compiled applications.  When a library bug
exists that can endanger system security, statically linked applications
become a significant problem.  Systems with many statically linked
applications are more difficult to keep up to date security and
stability-wise than other systems.

--
James D. Lockwood                    The (former) Getty Information Institute
System Administrator                       1200 Getty Center Drive, Suite 300
james () gii getty edu                                Los Angeles, CA 90049-1680