How not to manage a vulnerability
Following on from my previous posts, Ruby on Rails 1.1.6 is now out along with full disclosure of the vulnerability. There is also a new Rails security announcement mailing list which can only be A Good Thing™.
However whilst I think their speed of reponse has been excellent, their initial “security through obscurity” stance was inappropriate for both a) an Open Source project and b) one written in an interpreted language, and the rapid succession of releases implies they reacted too hastily.
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 assalients[sic].
...means nothing.
Regarding security through obscurity, we’ll release the full details of this issue once everyone has had a fair chance to upgrade their system. Source transparency is of little comfort if you just had your system compromised before you got a chance to apply the patch.
... means nothing too. Anyone wanting to know how the vulnerability worked (i.e. attackers) simply looked at the source, whilst the people not sure if they needed to upgrade right now were left in the dark unless they knew the internals of Rails intimately (i.e. not many).
Fortunately for me, the applications hosted here are low traffic and a brief downtime was acceptable to remain secure but I bet this was a real headache for the large Rails driven sites.
