KnowledgeTree & SAS - Debunking myth from reality

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

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.