Re: Clarification: LD_PRELOAD issue

[casper () HOLLAND SUN COM (Casper Dik)]

> 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