False security notice on twitter

Update: After being confronted with the details of this blog post, a retraction was posted on twitter (https://twitter.com/#!/vuln_lab/status/98858850534424576), but the security notice is still available on their website, and the description still mentions 3.0.1, even though the header has now been changed to 2.0.8. Please note that version 2.0.8 is severely out of date and was first released in mid-2009. The security notice still has all the errors below, and is still not considered valid by anyone on the bug genie team.

Hey everyone. This blog post was created to clear up any confusion around a false security notice posted by a pretend security lab on twitter. The complete security notice can be seen here: http://www.vulnerability-lab.com/get_content.php?id=45. I will explain why this security notice is false in a few seconds, but first I want to clarify something.

Real security companies looking for bugs, errors and security issues in code work closely together with vendors and projects to make sure the details are correct, and to – when possible – coordinate disclosure so that there can be a fixed version available at the time of publication. Neither of these things happened in this case, and in addition to that, there are several factual errors and inconsistencies in the report.

• The security notice claims to have found an issue in version 3.0.1. First of all, this is an old version – it was released about six months ago. We are currently at version 3.1.3.
• The security notice contains an outdated description of the bug genie. The description of the bug genie detailed in the security notice uses a project description we have not used at all in 2011. They claim it was copied from our website, when in fact this description is nowhere to be found on our website.
• The short description of the bug mentions version 2, not 3, and not 3.0.1. This is just another example of the sloppiness and unprofessionalism displayed in the report.
• The exception error code is taken from version 2, not 3 as claimed. Version 2 has been discontinued since version 3 was released. While we have released a few fixes for issues after version 3 was released, version 2 has been discontinued and has not been supported since January 31st, 2011.
• They have posted an exception message. There is no sql injection possible in the error they have described. Even if all the above was correct, there is still no security issue displayed. They have shown no proof-of-concept code. There has been no proof shown that this is a real security issue, and their recommended workaround describes the existing implementation in the claimed affected version (2-something).

Security notices like these serves no purpose. They don’t help. They don’t shed any light on anything. Whoever is behind this notice has not given us any chance to fix, confirm or deny the issue described, and no proof-of-concept code has been provided. The issue they claim to have found is not shown in their security notice.

While no software is perfect, you should not take all security notices for granted. Responsible security labs work together with vendors so a fix can be provided together with the disclosure, and in any case provides details about security issues to the vendor in question.

There is nothing to see here. Move along.

More database encoding (or: how not to have fun with UTF-8)

zegenie posted a short while ago regarding encoding trouble with The Bug Genie, especially those of you who use Greek or Russian alphabets. The good news is we have made some progress on this topic!

The root of the problem is to do with how The Bug Genie connects to the database. Each component has different encoding:

• Database: whatever you created it as (probably latin1)
• Tables and columns: UTF-8 (we create them as that)
• The connection itself: could be anything

The last of these is the crux of the problem. On my system (as I am from Britain), the connection is latin1. This is fine for me, as I don’t need any unicode characters. However, for those of you who do, this means that unicode data is inserted into a unicode table, but is converted to something else (such as latin1) in the process.

The net result is that it will look right on the screen, but in the database it is garbage. This is fine up to the point where you start trying to do stuff with it, as there is a potential for problems to occur with JSON and other unicode-specific things, as what is in the database is not unicode (it is infact latin1 or whatever)!

An example of this is to copy some Russian text into both the Title and Issue Description fields. It will appear correctly in the Issue Description but not in the Title (it will claim it is empty).

This is easily fixed by setting the connection to use UTF-8, by placing this call on line 539 of core/B2DB/classes/B2DB.class.php:

self::getDBLink()->query('SET NAMES UTF8');

Now, all unicode data will be stored correctly in the database. However, this now results in another problem!

Any mangled Unicode data stored in the database as latin1 will be outputted as stored in the database (as no conversion is going on). This means that the mangled text in the database will be rendered to the screen. Luckily this is easily resolved by outputting a dump of the database in a latin1 connection, and then reimporting in a utf-8 connection (the nice Unicode output is obtained on the latin1 export, not the mangle that you get if you exported as UTF-8). The following code will do this, but don’t do this unless you put in the above code change:

mysqldump -h localhost --user=root -p --default-character-set=latin1 -c --insert-ignore --skip-set-charset -r dump.sql thebuggenie
mysql --user=root -p --execute="DROP DATABASE thebuggenie; CREATE DATABASE thebuggenie CHARACTER SET utf8 COLLATE utf8_general_ci;"
mysql --user=root --max_allowed_packet=16M -p --default-character-set=utf8 thebuggenie < dump.sql

We will be continuing to work on these encoding issues for The Bug Genie 3.2.

Beta changes

For those of you following development in trunk/ directly, you might have noticed that there was quite a stir/hiccup over the weekend – and you’re very likely to experience hiccups during your day-to-day usage of the system in the coming days. Because we wanted to get the beta out instead of adding another backend update to the list of things that would postpone the beta, this upgrade has happened now instead of before the beta release. What upgrade am I talking about?

We just updated our B2DB database backend to a more advanced version which provides a lot of features we’ve been missing for a while, like a proper active record implementation, automatic object population and proper foreign objects loading. All in all a very successful upgrade, and one that has allowed us to remove ~1000 lines of duplicated code across all our classes. The best improvements are always those where you get to remove code!

What does this mean for you? Well, nothing for the previously released beta. It does, however, mean that there will be a little cleanup to do to get everything working with this updated database backend, and it will most likely mean that trunk/ will be in a fluctuating state for a few days. I’ve made sure that it installs and that you can use the frontpage, wiki, configuration page and project pages for now, and I’m cleaning up more as we progress.

Another change that is coming from this update is that the minimum required version of php is now 5.3. While we always recommend keeping your php packages up-to-date, we’ve tried to maintain php 5.2 backwards compatibility. However, with this recent database backend upgrade, php 5.3 is required. Following the discussion in our forums it was not an easy decision to make, but the move to a more capable stack of php technology has given us a lot more power to do what we want.

So, back to coding. Or sleep. Or both.