Re: LD_PRELOAD potential problems

[darren.moffat () uk sun com (Darren J Moffat - Enterprise Services OS Product Support Group)]

> Many UNIX systems allow you to "pre-load" shared libraries by setting
> an environment variable LD_PRELOAD.  This allows you to do interesting
> things like replace standard C library functions or even the C
> interfaces to system calls with your own functions.

Correct, but so does setting of some of the other LD_* variables.

Solaris has at least the following other variables that could be
used to achieve similar results:

LD_LOADFLTR
LD_AUDIT

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

Correct, but given that the process wasn't running as root all you can
do is screw up yourself.  This isn't a compromise of the system.


> From the new man page for ld.so.1:


 If an LD_LIBRARY_PATH environment variable is in effect  for
     a  secure  process, then only the trusted directories speci-
     fied by this variable will be used to  augment  the  runtime
     linker's search rules. Presently, the only trusted directory
     known  to  the  runtime  linker   is   /usr/lib/secure,   or
     /usr/lib/secure/sparcv9 for 64-bit SPARCV9 objects.

     In a secure process, any runpath specifications provided  by
     the  application  or  any  of its dependencies will be used,
     provided they are full pathnames,   that  is,  the  pathname
     starts with a '/'.

     Additional objects may be loaded with a secure process using
     the  LD_PRELOAD  environment  variable, provided the objects
     are specified as simple file names, with no '/' in the name.
     These  objects  will  be  located subject to the search path
     restrictions previously described.



What this is saying is that in Solaris (from 5.7 with the Kernel Update
106541-05 - which is not yet released) LD_PRELOAD for setuid programs
will not work unless the file is in /usr/lib/secure  which is by default
empty.


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

A lot of people go with this as good practice.  However there are a
number of caveats as to why static linking is not a good idea.

Issues with static linking
--------------------------

Static linking reduces the overhead when the program is started up, mainly
because relocations and other start-up activities are done at compile time.
However, static linking is generally discouraged. Here are some reasons :

* Static linking prevents libc_psr.so.1 from working for platform
  specifics. This library automatically enables dynamically linked
  programs from linking in platform specific versions of various
  library routines which are optimized for a particular platform.

* Static linking greatly increases working set size and disk footprint.

* Statically linked executables are NOT necessarily binary compatible
   between releases.
        eg. statically linked programs that use libsocket will
            failed if compiled on 2.5.1 or less and run on 2.6

* Patches to system libaries for bug fixes and performance enhancements
  are not automatically picked up by the application.

* Some debugging libraries/tools will fail to work properly.
        eg. malloc debugging.

* And most importantly you will not benifit from security or other
  fixes in the vendor provided libaries when patches are released.


When to use static linking
--------------------------

* The binary is critical to system operation when in single user-mode
  either for the startup of the OS or for disaster recovery.

* Statically linking a private (internal) libarary is okay.


Don'ts
------

* Statically link against libc
* Statically link against libdl



And finally there are no 64bit static libaries in Solaris 7 and we
will NOT be providing them in the future for 64bit.


--
Darren J Moffat