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
| ||
|
Message-ID: <8e3fa0f6050702004242b33db3@mail.gmail.com> 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
Powered by blists - more mailing lists