OA - Ubuntu
A blog about Ubuntu, mobile GIS and archaeology

KnowledgeTree & SAS - Debunking myth from reality

Apr 13, 2011 by Yann Hamon

I've received the latest newsletter from KnowledgeTree a couple of days ago. It goes along these lines:

How do I keep my business documents protected?

Your business documents must always be secure.  You need a vendor that takes security seriously.

Well, I won't argue with that - but I just want to point out that no, SAS is not the solution to everything. When you are using a provider with closed source software, it is just as secure as the provider tells you - which often means, not much, despite the price they'll charge you.

To make my point, here is a list of security issues, ranging from trivial to critical, that are still present in the latest version of KnowledgeTree. Those have been reported in January 2010 via appropriate channels - with regular mails querying about progress. I've got good reasons to believe many of these issues also affect the hosted version.

  • You can DOS any on-premise version of Knowledgetree using the files from /usr/share/knowledgetree-ce/bin - they are not protected by any htaccess or other form of access control - and run very heavy maintenance tasks. Reload a few times one or more of the following files:
    • md5_validation.php
    • recreateIndexes.php
    • storageverification.php
    And your website will be down. For a while.
  • The call_home.php file in the root folder writes any value posted to it to var/system_info.txt , and is also available to  unauthenticated users. The maximum size of a file in ext4 is 16TB, and the maximum post size is set to 2GB by KT - if var/ is not on a really big partition, you can just keep making requests to this file with big POST values and let it fill the partition.
  • Knowledge Tree lets the installation files in place, even once it is installed. If you try to access, for example: /setup/wizard/installWizard.php  - you will be said, rightfully, that KT is already installed - but that's unless you add ?bypass=1 to the query (really). Fiddling a bit there and you can easily trash the db and all. Not good.
  • There is a bug in the ZIP library KT uses. After I reported it, a statement was written on the wiki. Of course the latest community AND enterprise version distributed are... 3.7.0.2, bug included, and good luck finding the patch. Gzip archives allow files with relative paths in them. Try crafting a gzip file containing a file with a path like "../../../../usr/share/knowledgetree-ce/script/malicious.php" and use the bulk upload tool to upload it - that's right, any authenticated user can upload PHP files and execute them, potentially accessing all files, or worse.
  • You get the regular XSS too: In preferences -> Display name, try putting a </body> , or some other html - it will screw the display. This was also in the hosted version last time I tried. It escapes some javascript, but would allow, let's say, a hidden iframe with a virused PDF, to stick to the most common exploits in the wild. But this could be also more damaging, if the attacker enters an iframe with the following address:
  • http://KT/knowledgetree/login.php?redirect=admin.php%3Fkt_path_info=principals\
    /users%26name=pirate%26newusername=pirate%26email_notifications=on%26max_sessions=3\
    %26action=createUser%26new_password=test%26confirm_password=test . This would create a new user account "pirate" with password "test", should an admin display this iframe. Not too secure, I'd say.
  • The default install of Knowledgetree (enterprise edition) also leaves a Zend server with the default password configured. Don't forget to change it. Most people don't, and some searches on Google would confirm this.
  • You also get the boring ones: http://KT/knowledgetree/ktwebservice/download.php?code=test&d=test&u=%3Cscript%3Ealert%28%22%20helloworld%22%20%29%3C/script%3C

I'll stop there, there are quite a few more. The list of griefs doesn't stop there though, as Knowledgetree will not scale past a few tens of thousands of files (see my article on their wiki about that).

I understand it is not very nice to post about security issues in the wild before a fix has been released, but at some point it might be the only way to get them fixed - and if it doesn't help there, at least people will be aware of what they engage into when installing/purchasing KnowledgeTree, and existing customers will know that they've been misled.

What conclusions should we draw from that?

  • Telling people your SAS solution is secure is not enough.
  • When using closed source software, as much as with SAS solutions, you can't tell how secure the solution *really* is. So when you receive a newsletter/mail from a SAS company that tells you how much more secure their solution is, do yourself a favour: junk it.

PS: knowledgetree is also a Canonical case study. We learn that, thanks to Ubuntu, they now have "200 times the clients for a quarter of the cost". Interesting, eh? It's plain sad to see such a fiasco, remembering the time I invested working on KT extensions and analysing the code.

So long, KnowledgeTree.



Comments:

Hello Yann,

Thanks for putting this post together. I appreciate that you are disappointed that KnowledgeTree has decided to release new innovation under commercial license terms, and not free, open source terms.

As the KnowledgeTree team has discussed with you in the past, all of the above issues are either at present resolved, have workarounds available, are non-issues for behind the firewall or closed organization usage, or have fixes soon to be released to customers (the latter being those issues presenting a low risk).

As you point out, most of the above issues are not relevant to KnowledgeTree's cloud offerings, and where they are (IFRAME XSS) they are mitigated by closed organization usage. Despite the low risk to our customers, we are patching the IFRAME XSS issue next week.

Again, I am sorry we have disappointed you with our decision to focus on our cloud offering and hope that we can agree to respectfully disagree on KnowledgeTree's strategy.

Best, Daniel

Posted by Daniel Chalef on April 13, 2011 at 07:18 PM GMT+00:00 #

Hello Daniel, I appreciate that you are taking the time to answer here.
I fear you are mistaken though, several issues posted here do apply (or have applied) to the hosted version (XSS, even the installation files). Some of them might not anymore because KT has chosen to fix some security issues in its hosted solution only, leaving on-premise customers in the dust.

It is not true either that these issues have been fixed, or are non issues either. In fact there has been no KT release since I reported those. Skilled people would know how to exploit them.

Assuming everyone is behind a firewall is a bit much, too. Check your list of customers, and see if the Zend issue apply (hint: it does).

My point is: beyond the fact that KT Enterprise on-premise contains many security holes, there are reasons to believe those issues also apply also to the hosted version (some I tested and confirmed).

There are also reasons to believe there might be more issues than I discovered - I've surely overlloked some.. - but that will now go hidden behind marketing speech "you're safe, believe us".

The basic rules of security is to patch holes when they are known and to let customers know, with a new release, as soon as possible.

Really, you'd be surprised how many of your customers are still vulnerable to one or more of those issues. 3.7.0.3 will be warmly welcome :)

Posted by Yann on April 13, 2011 at 08:07 PM GMT+00:00 #

Oxford Archeology... creating history ;)

Posted by Vadim P. on April 14, 2011 at 02:33 AM GMT+00:00 #

Post a Comment:
Comments are closed for this entry.