Focus on Security

Geeklog: Focus on Security

Background

Those who have been around Geeklog long enough know the emphasis we put on security. Our roots began in security (Geeklog was created to run a security related website) and we were one of the first open source system in its class to feature a *nix-style permissions system. We believe our commitment to security is why our userbase has grown over the years and that is why we felt it is important to remind everyone in the GL community that the importance security plays has not changed.

To that end, we have created this page that will get you information related to Geeklog security. This will include updates on new security features, reports of possible exploits and security fixes. You all in the GL community make Geeklog what it is today and we always invite you to put an eye of scrutiny on the code we develop because we realize that even though security if front-of-mind for the developers, we still make mistakes.

Staying Informed on Security Releases

If you don't want to watch this page all the time to see when new security release come out, you do have an option. In addition to posting information here, we will also post information on new security releases to our Geeklog Announcement Mailing List.

The Lifecycle of a Security Report

If you believe you have found a possible issue related to security here is the process the Geeklog team likes to follow:

1. Email geeklog-security AT lists DOT geeklog DOT net with a complete description of the issue. If you have an exploit, give the steps you took to reproduce the issue. If you have a fix please include that as well (all due credit will be given for your fix). Please note that this email is a distribution list. It goes to the entire Geeklog team.
2. Within 24 hours the Geeklog team will contact you to inform you we have received the report and have begun looking into it.
3. Within 3 days we will report back if we were able to reproduce the issues. If we could, odds are we will have a fix at that time as well. Please be patient as sometimes security reports for one specific scenario often lead us to identify other potential areas that could be affected by the same exploit. NOTE: if we can't reproduce your issue we will give you another chance to submit a working example of an exploit. If you can't get one to work we will be forced to dismiss this security issue and we would politely ask that you *not* report this to the various security mailing lists.
4. After confirming a security report we will prepare a security release. All Geeklog security releases include the last version with an srX tag. So, for example, if this is the first security release for Geeklog 10.2.1 then the security release will be named Geeklog 10.2.1sr1. If another security issue is found after that then the subsequent release would be Geeklog 10.2.1sr2 and so forth.
5. Once the security release is prepared we will release it to this site. At that time we will contact you, the reporter of the issue, and that time we encourage you to report this bug to the various security mailing lists.

A Comment on register_globals

We are getting more and more questions as to why we require register_globals being ON. Well, being a bit of a legacy PHP application, Geeklog suffers from the common reliance of register_globals being ON with other applications in the same generation. However, despite the direction that was taken, Geeklog has been quite secure because we coded with the knowledge in mind. The real question you may have is why don't we change that?

Changing the code in Geeklog to use register_globals turned off is no small feat. Nearly ever page that process GET or POST data relied on register_globals being off. We could fix this but it would take a considerable amount of time and the regression testing would be a sizeable effort. Instead the initial decision was made to wait for Geeklog 2 to fix these problems. Geeklog 2 is the next generation of Geeklog that is in development (albeit slowly).

Despite our requirement for register_globals being on, Geeklog is very secure. In fact, to date we have not had any security reports that demonstrate that our reliance on register_globals was exploited.

[Update 2003-12-09] An exploit of register_globals was found in the Gallery plugin for Geeklog. Obviously that plugins is maintained by a third party but given the popularity of it we want to make sure users of the Gallery plugins read this article explaining the exploit.

[Update 2005-12-18] Starting with Geeklog 1.4 (currently in beta), future Geeklog releases will no longer require register_globals to be "on", although certain plugins and add-ons may still rely on that setting.

Injections

One of the more prevelant security reports we get with Geeklog is related to SQL and JavaScript injection. We have recently implemented the kses filter to limit the possiblity of JavaScript injection. We feel these latest measures will reduce the ability for users of a Geeklog site to do any harm through the use of client side javascript.

SQL injections are a bit tougher to handle in Geeklog, in part, because we do rely on register_globals to be on. The reason is we could attempt to identify and fix possible SQL Injection attacks if we were using the PHP superglobal $_REQUEST object as passing it to a function to test and fix SQL injection attempts. However, because register_globals is ON we don't access our data from $_REQUEST and, therefore, have to take more tedious measures to address the problem (which we have done). One other note, we don't recommend using MySQL 4.1.x with Geeklog because of the new feature in MySQL to concatenate SQL requests.

Security Releases

Please see our Security topic for details on past security releases.

Last Updated Friday, July 28 2006 @ 03:40 AM EDT