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.
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
My music selection makes 
look good
Recent comments
This theme was designed by Chris Wallace and is licensed under the GNU General Public License.
Check out his cool WordPress Themes. Released by Six Revisions in the year of the rat.
11 Aug 2006 7:01 am
I don’t know about large rails sites, but it was certainly a headache for the typo team. Especially once it turned out that 1.1.5 didn’t stop the denial of service attack.
Still, the work we did to get rid of the default @:controller/:action/:id@ route wasn’t necessarily in vain.
11 Aug 2006 7:01 am
And I think wherein you stated large scale rails sites were affected lies the crux of the problem. For all we know though, some larger-scale sites may have already patched this and told nobody though its highly unlikely. This is making it more and more of a problem for those companies with rails production teams to have need for security-minded people as part of them. dev is one thing, security-dev is another and being able to spot holes often happens after their exploited. Nice summary. - ben @ http://rubyonrailsblog.com/