>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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:45:56 PDT