The past couple days has been a busy time for those involved in the Rails open source project. Just as busy as the Rails core developers were the users running Ruby on Rails applications (such the Radiant content management system). On Wednesday, the project's developers released Rails 1.1.5. In the announcement of the Rails release, David August called upgrading the new version "mandatory" since the security vulnerability was so severe. However, he didn't want to go into the details to the exact nature of the vulnerability and only stated that, "The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assailants."
Every project team, whether its software is open source or propriety, faces the challenge of disclosing their software's vulnerabilities. Such disclosures can have positive and negative impacts on the software's users. For example, releasing the exact nature of the vulnerability can give contributing software developers and users an edge in how best to protect their site, remove the vulnerabilities, and address concerns for any security patches that may not fully fix the problem. However, as August mentions, releasing details of the vulnerability can provide information that could enable would-be hackers to cause damage to users of the software.
While it is common to see private companies not disclose vulnerabilities in their propriety software, such actions are seen less in open source projects. Just a few weeks ago, eWeek's Jim Rapoza talked about the need for software makers to fully disclose the vulnerabilities in their software through his article, "Web heroics wanted". In the article, Rapoza states that such a hero would not only make sure "that vendors didn't release code full of bugs" but also "make sure that software makers would act quickly to address any problems that did arise and not hide the problem from users". He further states in the article his reason for wanting full disclosure:
To me, a flaw that has been publicly outed is much better than one that a vendor has kept hidden—you know that the bad guys are already using these flaws, and, by knowing about them, you can protect yourself.
Focusing back at the security vulnerability in Rails, users of Rails appeared not to be happy with the lack of disclosure and commenting about that unhappiness within minutes of the initial announcement by the Rails developers. In an update early Thursday morning, August further emphasized the projects decision for not disclosing the vulnerability with a promise to release the information at a later date:
Believe you me, we take this extremely seriously. The entire core team is working on this investigation. We’ve currently made the trade-off to keep the details secret to protect people still in the process of upgrading. Once ample time for upgrading has been given and we have investigated this matter to its depth, we’ll release a complete report detailing all our findings.
However, Rails users still appeared unhappy with the lack of discloser and continued to comment further on the subject. One commenter, Gabriel Gironda (Comment #8), summarize the community's viewpoint when she replied:
I have to say I’m somewhat disappointed with the response of the core team. Knowing that the fix is in 1.1.5, and that 1.1.4 is flawed it’s fairly easy for anyone to take up the challenge of figuring out the problem.
I don’t claim to be King Ruby of the Great Kingdom Metaprogrammalot but when dev.rubyonrails.org actually allowed an svn export (I’m sure traffic was heavy there for a while) of the 1.1.5 code then it took a negligible amount of time to use FileMerge to sort through the changes and find code changes that relate to the issue.
I would rather have known what the issue was right from the beginning because myself and others in the Rails community would have had patches for all applicable versions pretty quickly. I don’t see any great gains achieved by stalling disclosure like this, and anyone with malicious intent can figure out the problem just as easily as I did (though I had the intent of preventing an attack by the aforementioned type of person).
I do of course appreciate the fact that the security flaw was disclosed at all, and that there is a fixed version available. Thanks!
Comments such as the one just mentioned, appeared to have been heard by Rail's core developers. By Thursday evening, August fully disclosed the security vulnerabilities found in Rails. In the announcement, August mentions that the vulnerability could allow hackers to take down a Rails process. He continued to urge Rails users to apply the appropriate patches of upgrade to Rails 1.1.6.
In Jim Rapoza's eWeek article, he states he is looking for a hero like Jack Bauer on the TV show, "24". This hero would push for full disclosure of security vulnerabilities by the makers of the software. However, in the case of Rails, there was no particular hero to our story. There was no single person that came in with guns blazing to tear down the bad guy. In fact, for Rails there wasn't even a bad guy, but a group of core developers searching for the right thing to do. In this case, and commonly found in most open source projects, there was no single-person heroics to be found. In this story, we found heroic users as a community coming together to voice their concerns. Heroic project leaders willing to listen the will of their users. Instead of finding a hero, we found heroes.