Bugtraq mailing list archives
Re: LD_PRELOAD potential problems
From: james () VANEYCK GII GETTY EDU (James Lockwood)
Date: Thu, 13 May 1999 15:47:31 -0700
On Tue, 11 May 1999, 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. 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.
I would hardly call 30 seconds with adb or gdb "a lot higher". Static linking is bad for many reasons, one of the chief being that if bugs are found in the libraries you are using there is no way to fix the executable. Static linking also wastes memory, and many Unices are starting to deprecate static linking of system libraries (Solaris is a good example). If you must have your program run in an unaltered state, then ask that it be installed setuid nobody (for example) and have it drop uid/gid privs in the first two lines of code. LD_PRELOAD (and LD_LIBRARY_PATH, for that matter) are not honored on setuid executables. If you are distributing time-limited crippleware, then nothing will help you. Those who want to bypass it will, but most will not. There is no way around this, as long as the user is downloading and executing your code under her control she will be able to modify it. Normally I wouldn't consider this a worthwhile discussion for BUGTRAQ, but I think that the point must be made that static linking prevents library fixes from being propagated to compiled applications. When a library bug exists that can endanger system security, statically linked applications become a significant problem. Systems with many statically linked applications are more difficult to keep up to date security and stability-wise than other systems. -- James D. Lockwood The (former) Getty Information Institute System Administrator 1200 Getty Center Drive, Suite 300 james () gii getty edu Los Angeles, CA 90049-1680
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)