Update Checker Question

6 replies [Last post]
michael38walker
Offline
Joined: 07/06/2010
Status: 
Answered

I perceive a huge security and privacy hole in the licensing system used by Moneyscripts. Call me paranoid if you like, but I have worked extensively in the corporate sector and have worked on and designed many systems which had to comply with company security and data-protection guidelines. Suffice it is to say that paranoia is the default position they all take, and there is no such thing as trust.

Moneyscripts modules have a "call home" "feature", which allegedly checks for license compliance and updates, but, and it is a huge "but", it uses some encrypted code - so we have no way of knowing what it is doing. Personally I am confident it is all benign, but confidence doesn't cut the mustard in the hard-nosed real business world of corporate security and data-protection.

Leighton, you say you are using the same technique used by the Drupal updates system, however, there is a world of difference between 1) our trust in the Drupal community and Moneyscripts (no disrespect intended); 2) anyone with enough knowledge can see what is happening under the bonnet with Drupal because the code is open source and unencrypted; and 3), unlike Moneyscripts, it is possible to switch off the Drupal update system (there are possibly other ways to do this, but one way I know of is the http://drupal.org/project/update_notifications_disable module).

It is one thing to try to protect your investment in code, but it is quite another to have what is in effect an encrypted daemon sitting on customer's servers which can invisibly do anything Moneyscripts chooses to do, and at any time... By all means check for license and updates, but give us the option to switch it off and, most importantly of all DON'T ENCRYPT IT - i.e. don't expose all our systems to this security vulnerability. For all anyone knows, Moneyscripts could be harvesting any information it likes - it potentially has access to any database and the filing system, it could plant viruses, anything...

Paradoxically, Moneyscripts could well be losing out on balance by using this security-exposed licensing approach. You could be losing more revenue by untold numbers of customers who would like to use the Moneyscripts modules but are put off by the security loophole, than the few, if any, license fees you could lose by a few people bothering to take the time to use your software without paying for it...

The best businesses succeed by providing great products (which you do), excellent customer service (which you do), and by not giving their customers any good reasons not to buy from them...

Abilnet
Offline
Joined: 12/07/2009
I also agree MoneyScrips

I also agree MoneyScrips -modules are great and support by Leighton is like a dream. However, I've also been thinking the "call home" -feature should be well documented.

michael38walker
Offline
Joined: 07/06/2010
It's not about documentation

No amount of documentation proves that what is being done by invisible software is benign. No amount of documentation makes software secure...

Abilnet
Offline
Joined: 12/07/2009
No amount of documentation

No amount of documentation makes software secure...

You're right. However, if documented, users may have better understanding, what's happening in the background.

Leighton Whiting
Offline
Joined: 06/02/2009
michael, I understand your

michael,
I understand your concern completely, which is why the 'call-home' script (as you call it) is NOT encrypted in any way. Have you looked at the code? It uses Drupal's built in XMLRPC to check with my servers when you run cron if there are any updates available for the modules, if your keys are valid. The modules do not depend on the 'call-home' functionality, and if you really don't want it, you can just remove that part of the code (it is well marked in the module and documented).

The feature is not intended to be a 'controller' in any way, nor is it intended to protect my code, which would be against the GPL. It is merely intended as a way for my customers to get faster and easier support for the product they paid for.

I hope this helps to clear up the issue, and in the future I would appreciate it if you would check the code before assuming that there is an 'encrypted daemon' sitting on your server. To reiterate, there is no encryption, and there is no security hole. You can check the code yourself to see what information is sent and what is returned.

I took the same view point as you did, that if I encrypted my code, more people would be put off from trying it because of that worry. I am a webmaster myself of several sites, and I know first hand that no one wants to introduce that kind of hole into their systems, or that kind of a dependency. If my servers go down, your sites are unaffected. :)

Sincerely,
Leighton Whiting

PS I changed the title of your post to better reflect what the post is about and to stop anyone from panicking about a non-existent security hole.

PPS I will add a feature request to make the check dependent on whether you have check for update turned on in your site settings.

michael38walker
Offline
Joined: 07/06/2010
Unreserved apologies

Hi Leighton,

Please accept my unreserved apologies for this ill-founded judgement. I was going by the information in this (and similar) forum article :-

  1. Jaybee,
  2. Yes, the source files of the module is all included. There is 1 file that is encrypted, it is the licensed php class file, which deals with validating the IPN from paypal before returning the IPN variables to the module. But it is a file which doesn't need to be changed, since all of the work is done with the module (such as acting on the IPN, creating accounts, adding roles, removing accounts, handling registration, etc. So 99% of the code is open source, editable by you. Hope that helps to clear things up.
  3.  
  4. Sincerely,
  5. Leighton Whiting

There are a huge number of forum articles - which are difficult to assess at the best of times, and updates and responses are not always that easy to locate. What started off my concerns was how your website "knew" what domains we are using your software on - without us specifying it anywhere!

I am very glad to hear of, and am very relieved by, the lack of source code encryption (I will take a look at the code when I have the time), however, for the avoidance of any doubt or concerns like mine, I suggest you make this a very, very, prominent point about this aspect of your software...

Best wishes for your excellent software and future prosperity, and once again, please accept my sincerest apologies for my genuine mis-understanding.

Sincerely,

Michael

Leighton Whiting
Offline
Joined: 06/02/2009
michael, Ah yes, that was

michael,
Ah yes, that was from one of the first versions of the software. That licensing has since been removed (it didn't take long until I realized what you realized in the first post and replaced it with the safer and more secure XMLRPC method above with no encryption). I am going to remove that forum post since it is no longer relevant and so it won't confuse anyone else. No worries about the post, I understand this is an important subject and can definitely see why you would be worried about it. I hope that your worries have been assuaged and that you won't hesitate to continue to post your good ideas and suggestions on these forums. Have a nice day :)

Sincerely,
Leighton Whiting

EDIT: I edited the post in question to state (correctly) that there is no encryption in the module files.

Twitter Feed