full-disclosure - plz suggest security for DLL functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat Jul  2 08:42:35 2005
From: sasha.lists at gmail.com (Sasha Goldshtein)
Subject: plz suggest security for DLL functions

> We are developing a software that makes use of a COM DLL. The whole
> logic lies in the dll. The User Interface is in VC++. DLL exposes
> functions, application calls it and displays result. Now, we found
> that anybody can copy the DLL, register it and make use of those
> functions.
> 
> Please guide us in making those functions secret or encrypted so that
> others cannt use our functions.

Ironically, nobody seemed to address the fact you're using a COM DLL,
not just 'some' DLL.  COM has a mechanism that addresses your basic
needs, although as many here pointed out, does not protect your code
from the prying eyes of more sophisticated attackers.

COM object activation is performed by a class factory object that
resides in the COM binary.  Normally, the class factory object would
not be re-implemented by the designer of the COM object, as it's
mostly boiler-plate code (implementing the IClassFactory interface).

However, COM does support a limited version of licensing by providing
a boiler-plate implementation of an alternative class factory object
interface - IClassFactory2.  Beside that, you can in fact write your
own class factory object interface, with the slight disadvantage that
the users of your COM object will then have to be aware of having to
use CoGetClassObject() and use it to create object instances, instead
of just calling CoCreateInstance() or using smart pointer wrappers (in
VC++), etc.

So if you don't need to protect your code (which resides in the COM
binary, whatever you do) from sophisticated attackers, you might want
to follow some licensing pattern and use the IClassFactory2 interface
or implement your own.

But if you want to take a more defensive approach, you could write
your own class factory object interface and have it implement security
measures such as those others on the list suggested.  It will make the
user of your object experience as little inconvenience as possible,
while at the same time providing the security you need.

Finally, I'd like to address the remote server issue brought up on the
list - it is possible to host the COM DLL on a remote server (using a
surrogate process), without resorting to implementing some sort of RPC
mechanism yourself.  Then, you have the option to exercise full access
control to the COM object using the dcomcnfg utility or by making
changes to the object code manually.

-- Sasha Goldshtein