Re: LD_PRELOAD potential problems

[kragen () POBOX COM (Kragen Sitaker)]

David Skoll wrote:
> 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.

First: the set of binaries you can set LD_PRELOAD for is the set of
binaries you can run from the command line.  Network servers that you
connect to on a box you don't have access to are not vulnerable to
LD_PRELOAD spoofing.

Second: the binaries you can run from the command line are of two
kinds, the kind that can do something you wouldn't be able to do
yourself, because they're setuid or setgid, and the kind that can't,
because they aren't.

Binaries of the first kind are not vulnerable to LD_PRELOAD on any
secure Unix system, because the kernel or dynamic linker makes sure
they aren't.  On the few poorly-thought-out Unix systems where this is
not the case, you can violate security in a much more direct way; you
can LD_PRELOAD libraries that directly do malicious things when they
are loaded, and they will be able to do them with the effective uid or
gid of the binary they are running in.  In short, on these systems,
nothing you can do short of removing LD_PRELOAD support from the
dynamic loader can give you *any* security.

Binaries of the second kind can be fooled into doing anything you want
them to, whether they are statically or dynamically linked, but that's
OK, because they can't do anything you yourself aren't permitted to
do.  (People who distribute copy-protected software may be concerned
about this statement.  People who remove copy protection for a hobby
will recognize it as obvious.)

In short: this is not a problem.

--
<kragen () pobox com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml