Welcome to Geeklog Thursday, May 23 2013 @ 10:34 PM EDT
Lukasz Pilorz has found 3 security issues in kses, the HTML filter we're using in Geeklog. We have examined these issues and to the best of our knowledge, 2 of the 3 issues are not exploitable in the Geeklog context, due to additional filtering done by Geeklog. The third issue is exploitable, though, but won't affect standard installs.
The exploitable issue affects the HTML style attribute. In a standard install of Geeklog, the style attribute is not allowed, i.e. filtered out when someone attempts to use it. This has always been our recommendation, as it could be used for defacements. Lukasz has demonstrated that it could also be used for XSS. Since kses is no longer maintained, there is no patch for this issue. We therefore want to repeat our recommendation: Do not allow the style attribute for normal users and be very careful when allowing it for Admin users.
For the other two issues, Lukasz has provided a patch for kses that we've rolled into Geeklog 1.5.0, just in case. For earlier releases, you can download a drop-in replacement for kses. Again, to the best of our knowledge, the issues (which include arbitrary code execution) do not seem to be exploitable in the Geeklog context.
Since kses is no longer maintained, we will be looking into replacing it with some other HTML filter in future Geeklog releases.
MustLive pointed out a possible XSS in the form to email an article to a friend that we're fixing with this release.
Please note that this problem only exists in Geeklog 1.4.0 - neither Geeklog 1.4.1 nor any older versions (1.3.x series) have that problem.
To upgrade from Geeklog 1.4.0sr5-1, download the upgrade archive. To upgrade from any other 1.4.0 version, please use the combo update, which also includes all the previous security updates.
Upgrades should be straightforward, as you only have to replace one file. Since security issues are often exploited soon after they become public, you should install this upgrade as soon as possible.
Since we had a few reports about hacked Geeklog sites again, all of which turned out to be due to running on old and insecure versions, I'd like to remind you to please check for updates regularly and if there is a security update, that you install it ASAP - in your own interest.
At the time of this writing, the following Geeklog versions are considered "safe" in that there are no known security issues with them:
The 1.3.11 versions are not officially supported any more, but sites running on the latest incarnation (see above) should be fine.
Security issues may also lurk in plugins and other add-ons that you have installed, so you may want to check those for updates as well.
CAPTCHA v2.1.2 has been released to address a security vulnerability I discovered in the code this morning. All CAPTCHA users are encouraged to upgrade as soon as possible. The upgrade process is very straight forward, simply copy over the new source files, then go into your Plugin Manager and select Update for the CAPTCHA plugin.
There is one other small tweak, if the session start fails, it will do so silently, no longer causing scripts to stop. This should resolve any issues with the emailgeeklogstories cron script.
If you do not want to upgrade to the latest version of Media Gallery, you should apply the following patch:
Edit mediagallery/maint/ftpmedia.php
Near the top, immediately before the following line:
require_once($_MG_CONF['path_html'] . 'lib-batch.php');
Add the following code:
// this file can't be used on its own
if (strpos ($_SERVER['PHP_SELF'], 'ftpmedia.php') !== false)
{
die ('This file can not be used on its own.');
}
Save ftpmedia.php. This should resolve the issue.
For more information on other enhancements and fixes to Media Gallery v1.4.8b, please see www.gllabs.org.
Thanks!
Mark
JPCERT/CC informed us about a possible XSS in the comment handling that we're fixing with the following releases:
Upgrades should be straightforward as you'll only have to replace one file (lib-comment.php for Geeklog 1.4.0 and comment.php for Geeklog 1.3.11).
To address the recently posted exploits for insecure installations and for the mcpuk file manager, we are releasing Geeklog 1.4.0sr4.
In this release, we've removed the file manager altogether, so you will no longer be able to upload images through FCKeditor (this will be enabled again when we release Geeklog 1.4.1 with FCKeditor 2.3). We've also added additional protection against code execution in case of insecure installations but suggest that you really protect your Geeklog install properly as explained in the installation instructions and in the FAQ.
We are not releasing any updates for these issues as they wouldn't make much sense. In case of the first exploit, it's really an installation problem that should be fixed and in the case of the file manager, files will have to be removed (as explained in the article linked to above).
Please note that the first issue applies to all Geeklog releases, while the second only applies to all the 1.4.0 releases.
While yesterday's exploit only affected incorrect Geeklog installs, this new one is more serious:
An exploit has been posted for the "mcpuk" file manager that we're shipping with FCKeditor in Geeklog 1.4.0. The exploit allows an attacker to upload and execute arbitrary code.
While FCKeditor is not enabled by default, this exploit works even when FCKeditor is disabled, as it calls the vulnerable file directly. So it is not enough to disable FCKeditor in config.php.
If you don't plan to use FCKeditor on your site, you can simply remove the entire 'fckeditor' subdirectory (from Geeklog's public_html). Otherwise, you will have to remove the file manager as explained below ...
In case you've been wondering about the increased amount of people trying to access a 'plugins' directory on your Geeklog site: Someone has posted a so-called "exploit" for Geeklog and all the script kiddies are now rushing to try it out without really understanding what it does and most importantly why it doesn't work on most of the Geeklog sites out there anyway.
So what is all this about? As is being pointed out in the installation instructions, everything that resides outside of Geeklog's 'public_html' directory should not be accessible via a URL. In other words, those files and directories should reside outside of your webroot. This applies to the config.php file, the 'plugins' directory, and everything else that resides there. The so-called "exploit" can only do harm on sites that have those inside the webroot, so that they can be accessed via a URL. And even then those that installed Geeklog that way but password-protected those directories (as explained in the FAQ) are also save.
Additionally, an internal code review has revealed another possible SQL injection in the story submission.
We are therefore releasing Geeklog 1.4.0sr3 (complete tarball, upgrade archive) and Geeklog 1.3.11sr6 (upgrade archive, combo update) to address these issues and would suggest that you install these as soon as possible.
Read on for more information ...
If you need help in setting up or using Geeklog, please see the documentation, the FAQ, the Wiki, try our search page or browse through the Support Forum. Chances are someone else already had the same problem.
More resources are listed on the support page.
If you still can't find an answer, feel free to post in the forum.
Need help now? Try our web-based IRC chat.