h0bbel.p0ggel.org

Both open source projects I'm connected to has released updated versions this week. While new releases are normally "good times ™" these two updated versions both address security issues.

The Gallery 2.2.6 Security Fix Release address three separate issues that was reported by Alex Ustinov and Hanno Boeck (more details are in the release announcement).

As for Habari, the 0.5.1 version is a minor release, but it addresses a single major issue found internally by the developers.

Be sure to upgrade if you run either of these!

One of my coworkers runs a Joomla based site for his Milsim Shop (wikipedia) and today he was faced with the following when opening his site:

Apparently it had been replaced with a defacement, like many others.

Seems to me that is that this is an automated attack exploiting vulnerable Joomla installs, where it exploits a security issue that allows for remote administrator password changes.

The issue was reported and fixed on the 12th of August 2008 when a new 1.5.6 release was made available. Joomla themselves has also been bit by this when a non-public development site was used to deface joomla.org itself.

So far it seems like all the attacker did was to change the administrator password and replace the template index.php file. I recovered the admin password my putting a raw md5sum of a known string manually into the MySQL database Joomla uses

Nice find by Scott Lowe, Virtualization Security Guidelines. Be sure to read though it if you manage virtualized servers, you might just get a couple of surprises.

The Gallery team has announced the new Gallery Bounty Program. Basically this means that if you report a valid security issue or create a patch for an existing issue or even implement a requested feature, Gallery will pay you for it.

Additional details, besides the announcement itself, can be found on the Gallery Bounties page.

Interview with Stefan Esser on Wordpress security. Very interesting read, and Stefan has some very valid points in regard to how issues are being adressed.

I would like to highlight two of the key points made in the interview:

If I recall correctly, the phpBB guys at one point used their collected money and payed a security company to audit the software. I strongly suggest that the WordPress guys do the same. I am quite sure that there are still several vulnearabilities in WordPress. The free audits that they get from people releasing advisories will never cover the whole code base.

One should think that given the success of wordpress.com, doing external revisions like this should be within reach for the Wordpress codebase as well. Of course, this would not extend to third party plugins and themes, but having someone not associated with the product review the core code for security issues would be a very good idea (tm).

I am very glad that Gallery 2 hires third party security experts to do code reviews for each of the major releases. It really does make me sleep a little bit better at night, and the Gallery 2 security track record has been very good due to this and it's great developers.

I would actually do two things: 1. Switch off the SQL error messages, because they give far too much information to potential attackers. 2. Ensure that the default SQL tableprefix is not chosen during installation.

This also makes a lot of sense. Not showing error messages to random browsers should be a priority. Error messages often display more information than any user should need to see, and having error messages shown is often a way for attackers to figure out a way to break into the system. Randomizing the SQL tableprefix would indeed make it a bit harder to try and inject data, but at the same time it wouldn't stop anyone from inserting data into the database if they have access to the installation. After all, the prefix needs to be stored somewhere and in such a manner that the application knows about it.