“Joomla!” had an extremely serious security issue arise earlier in the week. I’m pretty deeply involved in the project, and I happened to be on the Bug Squad chat when the news broke. The issue was not a SQL injection problem, as many sources have assumed but reported as fact. Ironically, it had to do with defeating a session security feature. The security problem was a programming error. “Joomla!” goes through extensive procedures to defend against SQL injection, and from version 1.5 onward, such a vulnerability in the core code is highly unlikely. [Extensions are another matter. I strongly recommend that users only install open source extensions that have either been audited or that have broad community support.]
Even though this problem caused a fair bit of damage, I’m very proud of how the “Joomla!” team responded to the problem. This was a worst-case scenario: the exploit was published with no advance notification, and it was dead simple to implement.
The first we heard of it was a post on the Dutch “Joomla!” forums. One of the Bug Squad team mentioned this in chat on August 12th at 15:50 EST. We immediately took steps to verify the issue, and then once confirmed, to remove the details from the forum post. A patch was made available for testing at 16:10. A full package release was made available for testing at 18:19. Announcement of the release was made on joomla.org at 18:57, and by 19:40 update packages were also available. That’s three hours and 50 minutes from report to full public release. If that’s not a record I’ll be surprised.
What is distressing is that a large number of security focused sites reported this as a SQL injection vulnerability, along with a variety of other erroneous or misleading information. Almost a week later, many have corrected their errors, but several have not. Considering that the “Joomla!” team responded so quickly, and that complete information was posted as the first item on the joomla.org web site before the exploit became widely known, this suggests that many of these sites simply repeated each other’s misinformation, rather than taking even the smallest steps to verify the report.
Granted a sample size of one event is not sufficient to draw conclusions, but if this is any indication of how “trusted” security information sources behave, then it is no wonder that whole security field has a serious credibility issue. These kinds of reports are extremely serious matters, with a lot of potential for damage. Certainly the timeliness of information is critical, but hopefully not at the expense of accuracy. The security community has a deep obligation to perform the simplest verification of facts before rushing to publication.
First off as a Joomla user, thanks for your work on the project. Yourcomments about the nature of the security breach being misrepresented reminded me of the breach found in the (sadly discontinuted) CPAINT AJAX framework.
I think it was in 2005 that a security hole was found in CPAINT by the development team, fixed and a new release was put out as a security update. According to the CPAINT dev team it likely was a security issue that was facing any AJAX framework. But nevermind that, the security sites when mad with “CPAIN security breached” articles.
I think security error can happen when it is not a so bad mistake.
[Ed. note: link deleted. This comment is either obvious or link bait. either way it’s not worth a link.]