Hacker News Reader

Comment by wycats | Hacker News Reader

For what it's worth, we'd like it if security vulnerabilities in Rails were disclosed to http://rubyonrails.org/security.

Obviously this situation is a bit more complicated, as a ticket was opened up, and a lot of community discussion occurred. In general, emails to the security list are taken extremely seriously.

View on HN

Where would one find that link? The link to "Bugs/Patches" on rubyonrails.org links directly to the GitHub issue tracker. A search on Google for "link:rubyonrails.org/security" finds only a single reference, and it is from someone evaluating how other vendors handle security issues. (My guess: it used to be linked, but then Rails moved to GitHub, and some intermediate landing page was lost in the shuffle.)

OK, here's a specific mistake made by a rails committer in handling this issue. drogus closed [this issue](https://github.com/rails/rails/issues/5239) without bothering to tell GitHub about it. This meant that fewer people saw it, and fewer people had a chance to tell GitHub about it. (One even thought of telling them about it, but unfortunately suggested that someone else do it instead of actually doing it.)

I think that perhaps the Rails team should have someone reviewing that issues were properly handled.

I would expect the guy who found an issue with GitHub to report it to them. Yes, the rails people could have, should have.. But they explicitly asked "him" to report and there is no word on whether he did it or not.

You're stating the obvious. Egor Homakov should have done a lot of things differently. But there is little that can be done about the behavior of bad actors in the rails community. With people on the team, it's different. Practices can be audited, mistakes can be pointed out, and the fine people in the Rails team can respond to criticism and improve their performance.

People are reading this as a vulnerability in rails when it is actually a vulnerability in GH's code. Your comment unfortunately is going to add to it :(.

What should he have reported to rails security team? Shouldn't he have been contacting GH security team instead?

Edit: Rails guides discusses the root cause and counter measures against these type of vulnerabilities http://guides.rubyonrails.org/security.html#mass-assignment

Serious question: how is that any different than leaving SQL injection points in place and then just documenting it?

If an app makes it possible to do SQL injections, whose fault is it?

What Rails have done is to have a particular default (whose correctness can be debated) and document how it can be exploited and how to safeguard from it.

You didn't really answer my question. Rails has all the helpers in place to sanitize input for SQL injection. Why in that case do they apply the defaults and not do so in this case? They both amount to making unwanted DB modifications.

This is clearly what the author of the blog post suggests, why do you assume the vulnerability is in GH's code ?

When I read "this vulnerability affects tons of Rails apps," I read that as a security vulnerability in Rails. I'm not a user of the framework, but I've heard "convention over configuration" often enough to think that if this was brought up in the Rails issues tracker, it should be prevented by convention.

If it affects "Hello Rails" the canonical example Rails application, then maybe it is arguably a vulnerability in Rails.

http://guides.rubyonrails.org/getting_started.html#say-hello...

The problem with this is that the getting started guide[0] uses this 'mass assignment' method in one of the examples (under section 6.8) without any mention of a caveat. The scaffolding does likewise.

You'd be forgiven for thinking there was no vulnerability, given the lack of warning over that sort of code, and the fact that Rails does a lot of 'magic' behind the scenes (especially since you're using their own helper classes to handle form input and such like).

[0] http://guides.rubyonrails.org/getting_started.html

Wrong. The system should not fail open.

The Rails Guides may discuss it, but this does not excuse the fact that for years the Rails core team knowingly shipped code (and generators that created) insecure by default code.

No, this isn't a "Rails vulnerability" in the traditional sense, but the level of immaturity and groupthink in the response to these issues being reported is staggering and somewhat shameful.

What is complicated about it? Someone finally called the Rails team out seriously on a long-standing well known security problem.

This is the type of ridiculous stuff we used to expect from PHP years ago.

Well, Egor's hack accomplished two things:

(1) it has seemingly embarrassed some rails committers into taking this seriously, whereas they dismissed the issue before;

(2) I bet there were at least 20 devs who saw this on HN, said fuck my life, and hopped on their vpn to check if their site is vulnerable.

No drama disclosures didn't accomplish either of these things. Hopefully github won't take it too personally, and Egor was actually (as he seemed!) careful not to break anything.

20? He listed four or five way popular websites alone. Egor is my hero for this week, so thankful for his wake-up call to the Rails world.

(And I am not being a hater here, I am also using Rails for some hobby projects & had to double check all my code. I somehow didn't even think about foreign keys in mass assignment... sigh.)

Reply on news.ycombinator.com