cmsmadesimple.org hacked?

[Woof]

This is what I see this morning (Jan 2 2008) in the homepage (Greenish area at the top level) heading of http://www.cmsmadesimple.org:

This site just got hacked by pit! CMS Made Simple 1.2.2 has a few critical vulnerabilities that need to be fixed asap! Wake up time dev team! I'm looking forward for 1.2.3 version.

Can somebody explain if this is the CMS 1.2.2 at cause ?

Thank you in advance.
Woof

[Woof]

Thank you Karolis.
What a way to start the year 
I wish it is something the Dev people will resolve soon; you have my gratitude and respect!

[tsw]

yup, there is a vulnerability in tinymce module. if you want to protect your sites for now uninstall and remove tinymce module.

new version will be released asap!

[Woof]

yup, there is a vulnerability in tinymce module

I was under the impression the heading level was "written" in the template itself and not with tiny. But CMSMS is so versatile, I guess it can be placed into the content area too. This is so sad, as a lot of people use the WYSIWYG feature of CMSMS as they do not have any html/coding knowledge and just want a simple way of adding content.

Keep up the great work. Lots of people appreciate your work!

[tsw]

sql injection isnt restricted to that module alone.

hotfix

http://cmsmadesimple.org/pastebin/1440

or uninstall and remove tiny untill new version is released

[Pierre M.]

Hello,

thanks to the dev for the response and the hotfix.

So, yet another SQL injection, in a module ? Does URL filtering prevent this one too ? If so, could the 1.2.3 release notes please state that "although all users having set up URL filtering are not concerned by this threat everybody should upgrade asap" ? I think it could advertise URL filtering hence increase its use hence prevent CMSms made sites defacing.

Pierre M.

[tsw]

there probably wont be 1.2.3. new tinymce module has already been released and is downloadable from the forge, in a moment it will also be available in modulemanager.

[hprofet]

Hello,

thanks to the dev for the response and the hotfix.

So, yet another SQL injection, in a module ? Does URL filtering prevent this one too ? If so, could the 1.2.3 release notes please state that "although all users having set up URL filtering are not concerned by this threat everybody should upgrade asap" ? I think it could advertise URL filtering hence increase its use hence prevent CMSms made sites defacing.

Pierre M.

the question is why doesn't cmsmadesimple.org use url filtering? Does it actualy stop this hack? How did this happen?
And how can I update my tinymce? In module manager there allready is a new version but it says 'Cannot download'. I can download everything else. I have tryed uninstalling it first but had no luck.
I hope a new version will be released. This is a major problem.

[cb2004]

This is a core module. Something needs to be done instead of keeping it quiet on the forums.

[wilfried]

Downloads and Support is hacked too.

[calguy1000]

CMS 1.2.3 will be released sometime today.

[Pierre M.]

Hello,

...url filtering? Does it actualy stop this hack?

You don't have to trust me. See for yourself :
-setup a webserver, a 404 page, a 403 page, some static pages and some URL filtering rules.
-try to access a wrong URL : you get the 404.
-try to access a good URL : you get the 200 content.
-try to access a filtered out URL : you get the 403 response before it could reach PHP behind the webserver.

URL filtering is powerfull. There is no reason not to use it on CMSms made sites.

Pierre M.

[styson]

Having only done one client specific module for cmsms, my understanding might be limited so I could be way off.  The current architecture of CMSms doesn't provide an abstracted data access layer that module authors can use even for the tables they are adding, something along the lines of PEAR's DB or MDB2.  These libraries offer quoting and prepared functions for use with SQL statements, both of which are recommended for stopping SQL injection.  This leaves all database access up to the module's author including preventing SQL injection.  Not knowing what the error was regarding the tinymce module, it might be totally unrelated so I'm just thinking out loud here... Having a built in data access layer that all modules use can make modules easier to write and make them safer, even for the novice developer.  Short of that, having a recommended approach to stopping SQL injections added to the module docs would go great lengths to help. 

IMHO all module authors should at least use mysql_real_escape_string() to cleans their sql statements.  Or better, if php5 is being used, prepared statements. 

As for the URL filtering.  That works great IF you have control of the apache server.  In hosted environments, this might not be an options.  Since it can be on or off, the programmer cannot assume it is on and must code accordingly.

Thanks to the Dev team for gerting out the fix for this so quickly

[hprofet]

Hello,

...url filtering? Does it actualy stop this hack?

You don't have to trust me. See for yourself :
-setup a webserver, a 404 page, a 403 page, some static pages and some URL filtering rules.
-try to access a wrong URL : you get the 404.
-try to access a good URL : you get the 200 content.
-try to access a filtered out URL : you get the 403 response before it could reach PHP behind the webserver.

URL filtering is powerfull. There is no reason not to use it on CMSms made sites.

Pierre M.

sounds very good in theory, my site uses it as well. The question here is did cmsmadesimple.org use it or not? If it didn't perhaps you should listen to your own advice. If it did...bad luck...I'm still waiting for 1.2.3 before I go to bed.

[calguy1000]

Having only done one client specific module for cmsms, my understanding might be limited so I could be way off.  The current architecture of CMSms doesn't provide an abstracted data access layer that module authors can use even for the tables they are adding, something along the lines of PEAR's DB or MDB2.  These libraries offer quoting and prepared functions for use with SQL statements, both of which are recommended for stopping SQL injection.  This leaves all database access up to the module's author including preventing SQL injection.  Not knowing what the error was regarding the tinymce module, it might be totally unrelated so I'm just thinking out loud here... Having a built in data access layer that all modules use can make modules easier to write and make them safer, even for the novice developer.  Short of that, having a recommended approach to stopping SQL injections added to the module docs would go great lengths to help. 

IMHO all module authors should at least use mysql_real_escape_string() to cleans their sql statements.  Or better, if php5 is being used, prepared statements. 

You're way off...  CMS Uses adodb_lite, which provides abstraction and quoting.  And it's used throughout CMS.  It's other products that we've encapsulated into a module that may not do this (TinyMCE is such a module).