OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: Clarification: LD_PRELOAD issue

Re: Clarification: LD_PRELOAD issue

Casper Dik (casperHOLLAND.SUN.COM)
Fri, 14 May 1999 17:55:53 +0200

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


License managers really only protect you again honest customers
using more (cconcurrent copies of) software than they paid for.

In that context, tamper proofing is perhaps ill advised because of both
the drawbacks and the ease of circumventing them:

	- statically linked binaries require you to release a new
	  version of your product each OS release, if you're unlucky.
	  I've seen statically linked license daemons break going
	  from Solaris 2.5.1 to 2.6 (-lsocket)
	  Solaris 2.3 or 2.4 changed the way gettimeofday() worked, so
	  statically linking that also broke.

	- in some cases (flexlm), you need to statically link both the
	  licensemanager and all products using it.


And the 3rd point:

	it's really not much more difficult to write an LD_PRELOAD than
	it is to write a program that uses /proc or ptrace() on
	system calls and substitutes return values of its liking.

	(I've done that for hostids on SunOS 4.x)


Statically linking raises the bar only a little; the maintenance costs,
however, may soar and customer satisfaction may very well decline.
(What do you mean, I need a different version of your product for
each of the four Solaris releases I'm currently using?  Can I have
a version with libc bug X fixed?)

Casper