James Bennett wrote: > On 8/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote: > > I can see how a policy like that is "tricky"... What's to keep an evil > > blackhat from subscribing to the very same list so he he knows when to > > get busy cracking sites using the same information? > > I've been watching people go round and round about this in various > places today, and I have to say that I can respect the Rails team's > policy of not releasing full details of the vulnerability until after > their users have had a little time to patch. Full disclosure still > happens, but it's slightly safer for end users this way. A couple > other open-source projects I've used/been involved with have followed > a similar policy of "update ASAP, and we'll release details once > people have had time to patch", and it's caused no harm that I've > seen.
There are two principle reasons the Rails issue has gone over badly with the community: 1. Forced upgrade to 1.1.5. This caused big problems for users on versions of Rails older than 1.1.4 - people still using Rails 1.0 for example. With hindsight, I think it's obvious to everyone that the Rails team should have prepared patches for other affected versions rather than forcing people to upgrade. Thankfull, Django security policy already takes this in to account: http://www.djangoproject.com/documentation/contributing/#reporting-security-issues "Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases." 2. The full disclosure problem. The argument against fully disclosing the problem seems pretty solid: it's a serious exploit (it appears to allow remote Ruby code execution) and they wanted to give Rails users a head-start on the attackers. Here's the argument against (for those who haven't been following along): - The flaw can be found by running diff against 1.1.4 and 1.1.5. Any half decent attacker could do this. The Rails team actually included a red herring (an SQL injection unit test) to try to throw people off the scent, but that was never going to hold back anyone with a modicum of talent. Once one black hat had figured it out it would spread quickly via underground mailing lists and IRC channels, leaving white hats at a disadvantage. - Because users didn't know what the flaw was, they couldn't evaluate the solution to confirm that it was going to work. More importantly, they had nothing to judge how urgent the upgrade was or if there was some other short-term measure they could take to protect themselves. The biggest complaints are due to a combination of the above factors. The initial announcement stated that more versions of Rails were affected than was actually the case. This resulted in some users spending hours upgrading their applications, only to later find that the version of Rails they were running was safe. This would not have been an issue had full disclosure let them (or the community) analyse the problem in more depth. It also wouldn't have been an issue if patches had been released for older Rails versions. Based on all that, I think the principle lesson from the whole thing is that getting patches out for older releases is critically important. Luckily this is already listed as Django policy. I doubt that full disclosure would have been as much of an issue as it has if they had got those patches out straight away. Like Jeremy said, this stuff is hard. Some good background reading on the Rails situation: http://weblog.rubyonrails.org/2006/8/10/security-update-rails-1-0-not-affected (the comments) http://www.ruby-forum.com/topic/76671 Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
