Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Clarification: LD_PRELOAD issueDavid F. Skoll (dfsDOE.CARLETON.CA)
Fri, 14 May 1999 09:17:25 -0400
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Casper Dik: "Re: Clarification: LD_PRELOAD issue"
- Previous message: Darren J Moffat - Enterprise Services OS Product Support Group: "Re: Solaris2.6,2.7 dtprintinfo exploits"
- Next in thread: Casper Dik: "Re: Clarification: LD_PRELOAD issue"
Hi, I feel I need to provide more context for the LD_PRELOAD issue. Yes, I'm well aware that set[ug]id programs ignore LD_PRELOAD and the other LD_* environment variables. The context is a software license manager. A commercial software organization wants to protect its software with a license manager which relies on accurate time information. Any user of the system, including root, must be viewed as a potential cracker. This is not your usual security issue. Now, any license manager can be spoofed, from as blunt an attack as changing the system time to sophisticated reverse-engineering attacks on the license manager binary. The issue is to prevent "cheap" attacks -- if attacking the license manager is expensive enough, people won't bother (or they'll find other avenues of attack. :-)) Changing the system time introduces all kinds of problems, so most potential license abusers won't do it. A two-line shell script with a 6-line C program is a very cheap attack on a dynamically-linked license manager daemon. Attacking a statically-linked license manager binary is quite a bit more expensive, and should greatly reduce the incentive for an attack. -- David F. Skoll