Re: LD_PRELOAD potential problems

[espel () LLAIC U-CLERMONT1 FR (Roger Espel Llima)]

On Tue, May 11, 1999 at 09:51:40PM -0400, 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.

Getting a program to misbehave, when it's running under your uid, is no
trouble at all.  Just ptrace() the thing, put breakpoints, change its
variables, etc.

(read-only programs are supposedly protected against this, but this is a
rather iffy kind of protection, and I woulnd't base a program's security
on it)

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

If you are writing programs whose security model counts the uid they run
as as a potential attacker, your security is broken by design.

If the ordinary user has something to gain by making the program
misbehave, then the binary should be suid to some other uid, and
explicitly make the appropriate security checks.  In that case, any
non-braindead dynamic loader will ignore LD_PRELOAD.

If the program counts even the *admin* as a potential attacker, then
good luck -- it's security by obscurity, just hope that no-one takes the
time to break it.

--
Roger Espel Llima, espel () llaic u-clermont1 fr
http://www.eleves.ens.fr:8080/home/espel/index.html