Security

Following on the heels of 1.3.8-1sr1 is 1.3.8-1sr2, available as a (tiny) upgrade archive as well as a complete tarball.

Jouko Pynnonen found a way to trick the new "forgot password" feature, that was only introduced in 1.3.8, into letting an attacker change the password for any account. This release addresses this issue - there were no other changes.

Users of 1.3.7sr3 are not affected (as the feature simply didn't exist there).

bye, Dirk

In response to the recent reports about (confirmed and unconfirmed) security issues in Geeklog, we are releasing updates to Geeklog 1.3.8-1sr1 and 1.3.7sr3, addressing most of these issues (but not all - see below for details). There's also a complete 1.3.8-1sr1 tarball that should be used for fresh installs.

The upgrades include Ulf Harnhammar's kses HTML filter to address possible Javascript injections and CSS defacements.

As for the (still unconfirmed) SQL injections, the upgrades include a fix to the database class that does not display SQL errors in the browser any more (they are only logged in Geeklog's error.log). While this does not safe from SQL injection attempts, it does at least avoid disclosing any sensitive information as part of the error message.

Furthermore, we do not at this time recommend to use Geeklog with MySQL 4.1 (which, I may add, is still in alpha state and thus shouldn't be used on production sites anyway). An upcoming release of Geeklog will address the remaining SQL issues, including any problems with MySQL 4.1.

I'm sure by now many of you have heard of the Geeklog security issues that have been posted on lists such as Full Disclosure and Bugtraq.

One of the issues mentioned in that post regards the injection of HTML in the Shoutbox and can easily be addressed, as explained in the story "Fix your Shoutbox!".

The more scary bits, however, are those of the acclaimed SQL injection. Three members of the Geeklog development team have now been trying to reproduce these issues - and failed. That's not to say that the issues do not exist, but it seems they are a lot harder to exploit than the post claims. Even the person reporting the issues couldn't (or wouldn't) produce a working example.

So, we are still looking into it and will come up with a solution to filter these injections, just in case, eventually. In the meantime, it looks like this issue is not as dramatic as it first seemed.

We would also like to point out that the person who published that report didn't contact us before doing so. It could have avoided a lot of confusion and even misinformation (the post even claims to have found the problem in a 2.x version of Geeklog that doesn't exist yet). This is certainly not a very professional way to handle security issues. Regardless, we are taking the claims seriously and we are looking into the matter as we speak.