Hi, Hopefully this is not out-of-line in this thread. I am a Rails person, not a Django person, although I have written a lot of Python in the past. I can give you some more information about the fallout in the rails community which might help you formulate your policy.
I agree with Simon, except that I think that close to full disclosure would have been much better considering the circumstances. What the problem came down to was that the patches offered by Rails core were very shoddy. They introduced new vulnerabilities where previously there were none, and broke a lot of applications. If they had kept quiet about the issue for a few more days and then released all the patches along with a small note "recommended security update", and a non-alarmist discussion of the source of the issue, there would not have been so much trouble. The primary cause of the problem had been reported in the ticket system for some months already, so it shouldn't have been a surprise. But suddenly someone in rails core realized you could combine that with another unrelated feature to cause data loss. If the patches had worked, people wouldn't have minded the zero disclosure so much. But without good patches and also without full disclosure everyone was left high and dry. Even partial disclosure would have helped a lot (and it was definitely a possibility, since exploiting the flaw requires a combination of unrelated parts of the application stack). People in situations requiring risk management had absolutely no options, and everyone lost a lot of time. Also, the response of some community members to those pressing for full disclosure was very nasty, along the lines of "it worked fine on my blog, suck it up and upgrade", "diff it yourself" (for a problem deep inside the application stack), and "we don't want the enterprise here anyway". Evan I am sure there are other sides to the story, but here is how I perceived it. Timeline (inexact) 5 pm EST: I was working on a plugin and the latest Rails svn co suddenly broke some auto-loading functionality. Inspection of the source showed sweeping changes in the routing and library loading. 7 pm: weblog.rubyonrails.org posts a hand-wringing warning: "This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn't affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.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." Channel #rubyonrails on freenode goes nuts. 11 pm: incompatibilities and breakages are being widely reported with the patch for recent Rails installs on Windows, and for applications that use a type of scaffolder called "Engines". Also, there are many known incompatibilities between Rails 1 and Rails 1.1.5. Response from core seems to be "suck it up". Everyone starts manually upgrading their old apps. Not wanting to upgrade one of my apps from a May svn co, but obviously not having a specific patch for that random revision, I investigate the changes along with some others on IRC. 3 am: first reports from diff'ers willing to publicly disclose appear on ruby-forum and on personal blogs. Accuracy increases as the night goes on, but basically we had it right. The vulnerability seems severe but not impossible to migitate without resorting to patches. 4 am: same people report that there is no reason to think that Rails 1 is affected. Also, the 1.1.5 patch is incomplete and apparently introduces part of the vulnerability into previously safe Rails 1 installations. 7 am: Rails core confirms that the vulnerability does not effect 1. 7 pm: Rails core posts a new patch, 1.1.6, to fix problems in the previous patch, as well as backports to all affected tags. Testing on all combinations of webservers and rails versions is still going on, and the patch might not be final. The patch does still not support Rails Engines. They also partially verify what the actual problem is and suggest that their hand was forced by the reports circulating on the web. Simon Willison wrote: > 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 -~----------~----~----~----~------~----~------~--~---
