Using compiled modules

[met00]

My client provided me with code for your shopping.com feed that they wanted to install. I went to validate that the code in fact didn't violate their terms of use and privacy policy. I was unable to do so.

Let me explain the problem. pre-compiled code may contain in it things to ensure your security (the code is being used and purchased on only the one site it is licensed to), but I am libel for ensuring that the code doesn't do anything that is malicious and violates their security policy. For instance, I can not confirm that your code doesn't use cURL to find out the last time it was run and grab the e-mail addresses for customers that have added accounts since the last run along with their billing data and then uses cURL to send them to a server where that information is then used to spam my clients customer base (since I can easily write such a module, I know that it is only not possible, but would be very easy to add that functionality to the code and no one would be the wiser if they ran the compiled code). Such a piece of code included in the compiled product would in fact be a massive violation of their security policy.

Since you are not a US based company, if you were to do this I would have no legal recourse against you if the client were to find out that this was done and sued me. Because of that, unless I can confirm the source code I can not have my client add the product to their store.

So, it becomes a matter of trust. I need to see and confirm the source before I will let the code run (and I will run the source, not the compiled version). I will make whatever promises are necessary to ensure that the code reports back to you and confirms the runs (which I assume is what is embedded in the compiled code). But, unless I can be assured that I have looked at all calls to the database and that the code doesn't in any way do anything that violates their terms of use policy or the privacy policy, I am afraid that I can not run the code.

When you purchase and use a pre-compiled module you are assuming that the module is ONLY doing what the vendor stated. I can easily see a company adding a cURL call to their site that:

1) uses cURL to go to their site and looks at the last day run
2) gets all e-mail addresses and personal data on the customers from that date to current from the database
3) packs the data into a CSV file and uses cURL to post that data to a third party site
4) updates the run date via cURL on their website
5) then does what you paid for

If I can write this simple piece of code (and I can), how can I know that this simple piece of code does not exist in the code processed and encrypted via zend?

The bottom line is that I can't. And if I can't then I can not be assured that the application is not violating the privacy policies of the site and is not passing data that is supposed to be secure to a third party for nefarious purposes.

So, this post is really to make sure that you, the reader, are aware of the exceptionally high risks associated to the use of compiled code modules against your shopping cart application.

As the used to say on Hill Street Blues. "Be careful out there."

[MindTwist]

huh...?
So what is this post about, again?

[michael_s]

Simply put, this is a cautionary article. If you purchase an addon module for osCMax or osCommerce, make sure the vendor can be trusted. It is very simple for a not-so-ethical vendor to start stealing private information about your customers.

There are ways to verify what the code is doing, but it is not easy for a non-programmer do do.

[met00]

Actually the vendor stated that the solutions is to "use a firewall" to make sure that everything "outbound" from the machine is turned off. Which may be a solution for those people that sit on their own server and don't use cURL for any of their own stuff (like getting shipping information from UPS, or processing payments in the background). But is NOT a solution in the real world.

They also states that they have "thousands" of satisfied customers in their six years in business. That may just mean in six years no one has been able to catch them doing it. Which is not proof that they don't.

As Michael states, this is cautionary. Before loading anything into your store, read the code. But if the module is encrypted and you can't, then be very concerned. Use a product like mytop to watch database access and see what SQL statements are being run against the database. Run an outbound sniffer to see if the application makes any calls out of the system. Watch FTP logs. etc.

But always be aware that malicious code can exist and that the encryption of the application can and does increase the risks for such malicious code to be operational on your server (in fact, if I were writing such code I would even set it up to not do anything until the applications filedate is six months past so as to ensure that the user was happy with the application and using it a great deal before I started to steal personal information from the shop). If I can come up with a way to "do it" and not get caught (and I have) I have to assume I'm not the smartest programmer out there, and that someone else can think up those things too.

[michael_s]

Yep, the firewall, packet sniffer, etc. A way to test for delayed malware is to change the dates manually or change the server date. It can expose time delayed malware pretty easily.

Of course, there are also legitimate reasons to encrypt code and to 'phone-home'

Take modernbill for example (a very widely used billing system). Encrypted and phones home, but I trust them as a reputable company and have used their software for about 5 years.

Ultimately, a business relationship is based on trust, and you have to determine whether you can trust a company. If not, don't use their product. For custom programming, if you don't fully trust the programmer, inisist on open source or move on

[MindTwist]

As Michael says, if I do not trust a company, I will just not use their programs, no matter if the code is encrypted or not. It is pointless to be scared of any kind of program (OSC related or anything else) just because you can not peek at the source.


And from the programming point of view, if I was selling a program and someone demanded to have the source on purchase or anything else like that I was not confortable with, I would just tell them to keep looking. One of the two parties is not interested on the business? No big deal, live goes on.

[met00]

In the US we have this unique concept of liability. Now if you are dealing with your own store and your own site, this doesn't apply to you.

As a developer I take a certain level of responsibility for ensuring the software used does what it claims. In addition, I am responsible for writing software that doesn't violate the terms of the agreements I have with my clients. When my client states that my software MUST ensure that their terms and agreements (ie: privacy policy) must not be violated by the software I deliver then I must be assured that the software doesn't violate the terms and agreements.

If the software "phones home", and that is all it does, I have no problem with that. I know of many people that put software that does that into the market to ensure that the software is only being used on IPs/domains that have licensed the software.

But, when I can't look at the code to validate that the software does no more than that, then I am putting the client at risk. And in todays litigious marketplace, that risk is NOT worth taking.

My article was posted, not to blast any company (note that I didn't make mention of the company name), but to make sure that people are aware of the risks associated with using software that is encrypted.

Yes, it is a matter of trust, but as one US President once said, "Trust, but verify." My clients rely on my ability to deliver solutions that meet their needs and do not put them at risk. If I can think of ways around packet sniffers, etc. so can others. I may have written a book on web programming, but I am NOT the smartest programmer I have ever known, and I know that there are many out there that can and may add a small function here or there that does more than I want done on my clients machine.

We spend a bit of time here talking about security issues from time to time. From protecting directories to sql injections. The nice thing about open source is that I can go through each and every line of code, as can anyone else, and we all can work to close loopholes, tighten security, make sure that the software is safe. I think it is also important to know that there is a massive risk in using software where the only thing you have to assure yourself that it is "safe" is the word of a vendor.

Sequioa voting machines were considered safe, until they were hacked. These are the people that "count the vote". I was once told by one very wise person that as soon as you let any machine talk to any other machine, that second machine will never be "safe" again. There is some truth in that. But with thousands of eyes looking over open source code, it gets safer. When someone locks the code up through encryption it is far less safe. When that person has no legal liability (overseas) then they have no reason to make my or my clients safety a priority.

Now, we can debate the whole "trust" issue until the cows come home, but the purpose of this article was to ensure that people maintain an awareness of the reasons why they should be very suspect of encrypted software.

And yes, as a developer I did walk away from this vendor. I will write the same basic routines myself. Then, after I have written and tested the software I'll release it open source to the community here and at the osc contrib area. With any luck it will be as good, if not better than the commercial product (and if not as good or better in release 1, by the time enough people are done enhancing it, it will be better). In the end, over time, more people will start to use the open source version and the vendor will end up losing their markets. So, in the long term, they will lose, all because I don't trust an overseas company with my legal liability, and they didn't trust me to make sure that their software didn't violate my clients terms of service.