Homakov, what we all want is to fix security bugs. There isn't any justification for thinking that we aren't all in the same boat on that. Things get muddy when you hinge the reporting of a security issue to your personal assessment of what a good architectural pattern is, though.
So please. I implore you to change your ways. You can be a great part of this community and you can build a reputable security consulting business without resorting to these irresponsible tactics. We will get this specific issue fixed shortly (as soon as the GET .js solution by adding xhr headers has been vetted), I'm not in the least concerned about that. I'm concerned that we'll be right back at square one next time you find an issue and you arm the internets with 0-day exploits against a random selection of applications before giving the makers a reasonable timeframe to defend themselves (one holiday weekend isn't it). On Dec 2, 2013, at 8:30 AM, Egor Homakov <[email protected]> wrote: > > Homakov rejected outright initially as a possibility > https://twitter.com/homakov/status/406466616897986560 > Sorry for using "REMOVE THE FEATURE" wordings, now I see how it sounded. All > i wanted is to fix security bug itself, throwing the feature away wasn't my > goal. > > > On Monday, December 2, 2013 11:18:59 PM UTC+7, DHH wrote: > I feel entirely comfortable with shooting down REMOVE THE FEATURE as the > first response to any security reporting. Our response should be, as it was > here -- as it always is, let's fix the issue. This is doubly so when security > reportings are conflated with other architectural agendas, like "dinosaur > feature removal quests". > > As it turns out, there is a very reasonable proposal for fixing this as well: > Check js requests for xhr? and add the xhr header to all js requests through > the framework, so it'll work for GET as well. We'll get this proposal vetted, > of course, but if that pans out, it would be an entirely invisible fix that > requires zero adjustment of the architectural style. Just like I mentioned it > would, and as Homakov rejected outright initially as a possibility. > > Yes, there are many ways to make a buck, if you don't care about how you do > it. I don't find that worthy of celebration. > > On Dec 2, 2013, at 8:13 AM, Rodrigo Rosenfeld Rosas <[email protected]> > wrote: > > > Your first message in this thread. He even quoted the relevant part in his > > article: > > > > "Not only are js.erb templates not deprecated, they are a great way to > > develop an application with Ajax responses where you can reuse your > > server-side templates. It's fine to explore ways to make this more secure > > by default, but the fundamental development style of returning JS as a > > response is both architecturally sound and an integral part of Rails. So > > that's not going anywhere. > > > > So let's instead explore ways of having better escaping tools, warnings, or > > defaults that'll work with the wonders of RJS." > > > > I understand you had the best of the intentions, but I wouldn't have > > started the discussion by ending it. By this time you were not yet aware on > > how applications were affected and if there was a sane way to fix this > > issue. If I were you, I'd first *ask* if there's an alternative way instead > > of deprecating its usage *before* deciding it wouldn't go anywhere. > > > > I guess that was what pissed him off... > > > > I agree with you that this is not the "correct" way of dealing with the > > situation, from an ethics perspective, but let's be honest: Homakov > > wouldn't probably be a known name if he hadn't put the attack to GitHub > > into practice. I'm not defending this approach to self marketing, but you > > can't tell us it isn't effective ;) > > > > Best, > > Rodrigo. > > > > > > Em 02-12-2013 14:01, David Heinemeier Hansson escreveu: > >> What email is that? I replied to Homakov on Twitter thanking him for the > >> discovery and stating a clear intent to get the issue resolved. What I > >> rejected outright was the knee-jerk reaction to remove the possibility of > >> generating JS responses from Rails. This rejection was confirmed when it > >> got clear that the motivation behind that specific mitigation strategy was > >> also motivated by architectural opinions on what's dinosaur and what's > >> not. > >> > >> But again, even having this discussion here or on Twitter simply isn't the > >> proper forum to discuss 0-day exploits. It's the reason we have a > >> standardized security reporting and response protocol. It's why we go to > >> great lengths to coordinate proper fixes across multiple versions of > >> Rails, following the CVE process, and other responsible steps in the > >> process. > >> > >> To sidestep all that doesn't help anyone but Homakov in the short-term to > >> build a reputation as a take-no-prisoners grey hatter. I question the > >> business strategy of that long-term (imagine having a business dispute > >> with Homakov after giving him access to your system -- yikes!). > >> > >> Again, my opinion of the process is removed from the value of finding > >> security holes. Of course finding and responsibly disclosing security > >> holes is a good thing. I just wish that Homakov, and others who might be > >> inspired by his tactics, would realize that there's plenty of gain to be > >> had personally by subscribing to these time-tested practices. > >> > >> > >> On Dec 2, 2013, at 7:52 AM, Rodrigo Rosenfeld Rosas <[email protected]> > >> wrote: > >> > >>> David, first I must say I admire both you and Homakov and I'd certainly > >>> hire him if I could afford it. > >>> > >>> I believe what led him to create that post was exactly your reponse to > >>> his e-mail. > >>> > >>> I agree he shouldn't have created this discussion publicly but you > >>> shouldn't have replied the way you did either. You should instead try to > >>> understand the problem first before saying it would go nowhere. > >>> > >>> I believe this is what caused Homakov reaction. > >>> > >>> Sincerely, > >>> Rodrigo. > >>> > >>> Em 02-12-2013 13:47, DHH escreveu: > >>>> Please stop conflating the discovery of a security issue with the > >>>> philosophical waxing about architecture. It's not helping the case. As > >>>> stated previously, responding with JS is not only a wonderful > >>>> architectural pattern, it's also not going anywhere. Not in a gem, not > >>>> in a deprecation, not anywhere. We'll fix the security issue, and Rails > >>>> will continue to proudly champion the use of this great pattern. > >>>> > >>>> Guess what, it won't be the last security issue Rails ever has. Just > >>>> like it won't be the last security issue any piece of software ever has. > >>>> But we need to level up as a community in our handling of these issues. > >>>> > >>>> Frankly, I'm surprised that people are willing to hire Homakov for any > >>>> work in the area given his reputation for irresponsible disclosure. > >>>> Finding a legit security issues is a great services, but disregarding > >>>> all security issue management protocols in their publication is doing a > >>>> disservice to all who would otherwise benefit from the work. > >>>> > >>>> Rails has had a codified security process for many years now. It's > >>>> available for all to read on http://rubyonrails.org/security. Making a > >>>> blog post on your personal site isn't one of the channels listed as a > >>>> responsible way of disclosing discoveries. Posting specific 0-day attack > >>>> vectors against affected sites is not one either. > >>>> > >>>> Making a public report over a holiday weekend, and then, when the > >>>> response to the report doesn't immediately follow the proposed solution > >>>> (remove the feature), go off the reservation with specific attacks is > >>>> just plain irresponsible. No two ways about it. It also goes to > >>>> undermine any other recommendations or suggestions coming from said > >>>> reporter. > >>>> > >>>> So. Damage is already done for this issue. But lest it encourages others > >>>> to act as irresponsibly as Homakov has done of this issue, I hope others > >>>> take a broader approach for future issues. Report systemic or framework > >>>> issues per the reporting instructions on > >>>> http://rubyonrails.org/security. Report specific application issues > >>>> directly to application developers responsibly per their reporting > >>>> instructions (see https://37signals.com/security-response for the one we > >>>> use at 37signals). > >>>> > >>>> Presumably we're all in the same boat here: Make Rails better and more > >>>> secure. Let's row like we mean that. The Rails security team (Michael > >>>> Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the > >>>> past to provide us with a good process, they've followed that process, > >>>> and they deserve our thanks and support. > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Ruby on Rails: Core" group. > >>>> To unsubscribe from this group and stop receiving emails from it, send > >>>> an email to [email protected]. > >>>> To post to this group, send email to [email protected]. > >>>> Visit this group at http://groups.google.com/group/rubyonrails-core. > >>>> For more options, visit https://groups.google.com/groups/opt_out. > >>> -- > >>> You received this message because you are subscribed to a topic in the > >>> Google Groups "Ruby on Rails: Core" group. > >>> To unsubscribe from this topic, visit > >>> https://groups.google.com/d/topic/rubyonrails-core/rwzM8MKJbKU/unsubscribe. > >>> > >>> To unsubscribe from this group and all its topics, send an email to > >>> [email protected]. > >>> To post to this group, send email to [email protected]. > >>> Visit this group at http://groups.google.com/group/rubyonrails-core. > >>> For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "Ruby on Rails: Core" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/rubyonrails-core/rwzM8MKJbKU/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at http://groups.google.com/group/rubyonrails-core. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Ruby on Rails: Core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/rubyonrails-core/rwzM8MKJbKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
