Security companies, distributors and reading ...

05/11/2008
There are moments, when a developer leans back after a release, concentrating on planning work for the next release to come and suddenly gets a mail on the devel list telling him about an security advisory about a bug he himself fixed about two months ago. For economy reasons the publically accessible news entry for users and developers contains the information on two distinct problems: One arbitrary remote code execution issue, which requires a system to be compromised by itself already (controlled by the attacker) or affected by another remote code execution issue in other third party software that gets executed before GeSHi runs - or to make it short: The door was open BEFORE the you could use the bug. In an attackers view, that issue was unnecessary to mention, because an attacker won't use it.

So well, maybe they mixed things up and ment the Denial of Service attack you could drive against GeSHi which had an real impact - in my tests I accidentially drove one server into the corner making the owner to having to reboot it. No - they didn't notice that one because the report clearly said "fixed in 1.0.8.1" AND the impact clearly stated "remote code execution". In an attackers point of view I'd clearly prefer the bug fixed with 1.0.8 instead of relying on an issue I won't be able to take advantage of.

So please, Secunia: Read bug reports provided by vendors, before you post your notices on unnecessary information on isues not relevant for attacks. Also I'd appreciate it if you at least could write the programs names correctly that you are reporting about. Furthermore you should use the contact information provided by the project management and contact them if you don't understand things or have information for them. It's simply annoying to get informed by third-parties of an issue of near-zero revelance, when there is public information on critical issues you can use to DoS a remote system.

Well, so far for security companies, now on to Debian package maintaining: I really like Debian, except for one point: You can't use testing for reasonably current software - instead you have to use unstable or even experimental. I know, testing should become more and more stable over time until it becomes the next stable at one point, but in my oppinion that shouldn't automatically mean that you freeze a package at a point where there is enough evidence of that particular version having more than just a few minor issues compared to updated versions. Instead you're botching around in an outdated version trying to backport patches for issues that can't be easily ported there, because the code evolved. This might work for the remote code execution issue that just changed one routine, but it won't work for the Denial of Service error in 1.0.7.22 because fixing it means to actually improve the parser, which in returns means, you just could update to the latest upstream version. So if you please could drop that package botching crap and let the upstream authors decide on how to handle things or at least give them more control on their software? Thanks in advance!

On a final word after all that complaining I would like to thank the people from the MediaWiki packaging team for their great work and efforts in packaging the latest versions of GeSHi that fast after a new release has been out. Keep up your good work!

BenBE.