Bugtraq mailing list archives
Re: LD_PRELOAD potential problems
From: darren.moffat () uk sun com (Darren J Moffat - Enterprise Services OS Product Support Group)
Date: Fri, 14 May 1999 09:45:44 +0100
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
Current thread:
- LD_PRELOAD potential problems David F. Skoll (May 11)
- Re: LD_PRELOAD potential problems James Lockwood (May 13)
- pIRCH32/98 Exploit Mike Arnold (May 14)
- Re: LD_PRELOAD potential problems Roger Espel Llima (May 14)
- Re: LD_PRELOAD potential problems Phillip Vandry (May 14)
- TGAD DoS John Daniele (May 14)
- Netscape Communicator bookmarks <TITLE> security vulnerability Georgi Guninski (May 16)
- <Possible follow-ups>
- Re: LD_PRELOAD potential problems Kragen Sitaker (May 13)
- Re: LD_PRELOAD potential problems Darren J Moffat - Enterprise Services OS Product Support Group (May 14)