Live data from Hacker News

Hacked: commit to rails master on GitHub

github.com

21–30 of 240 posts

Re: Hacked: commit to rails master on GitHub

#21
post #9

I'm confused. Is this a generic Github vulnerability or is this a vulnerability in tools outside of Github used by Rails? The 'hacker' seems to suggest it's the former ("Github pwned"), which would be pretty serious stuff.

He registered a commit using his own account - so he either got the password of a rails admin or he must've found a way to add his keys to the rails github account directly. The comments on the commit mention he just raised an issue that few people protect the attributes on their models from mass assignment, which… is one way this could happen. Kind of a dick move, though. Responsible disclosure, doing it on a Sunday…

  > Responsible disclosure
If you look at the bug report, the core Rails Dev Team basically said that they like the defaults the way that they are. They have/had no intention of changing the defaults, and are trying to push responsibility on to the developers using Rails to use sane config settings.

Looks like the guy did report it and the response was: "Not our problem" / "Not an issue." He got frustrated and decided to make a very public example of how this is bad.

Re: Hacked: commit to rails master on GitHub

#22
post #20

It's unfortunate that the guy stumbling upon this apparently noteworthy vulnerability happens to be so utterly immature . [EDIT: Unsurprisingly, the dude's 18. See http://homakov.blogspot.com/p/about-me.html for reference.]

On the other hand, this makes for a hilarious perusal of his blog.

Re: Hacked: commit to rails master on GitHub

#23
post #8

If this is a GitHub exploit, and I were GitHub, I would be talking to law enforcement. This is not how adults disclose software vulnerabilities.

I don't think adults react to harmless (if public) disclosure by tattling to law enforcement either, though.

If we're discussing how adults act, then I definitely would not refer to reporting a crime as "tattling" (I might expect that from a child in Elementary school, though). Zero-day attacks are extremely irresponsible, and this is probably against the law.

Re: Hacked: commit to rails master on GitHub

#24
post #9

I'm confused. Is this a generic Github vulnerability or is this a vulnerability in tools outside of Github used by Rails? The 'hacker' seems to suggest it's the former ("Github pwned"), which would be pretty serious stuff.

He registered a commit using his own account - so he either got the password of a rails admin or he must've found a way to add his keys to the rails github account directly. The comments on the commit mention he just raised an issue that few people protect the attributes on their models from mass assignment, which… is one way this could happen. Kind of a dick move, though. Responsible disclosure, doing it on a Sunday…

He's being an asshole. On the other hand, if the defaults in Rails lead even strong Rails developers into making mistakes, perhaps it is time for Rails to develop an "opinion" about this.

I hope the asshole messenger doesn't obscure the importance of the message because people often push back harder against a message when it is delivered in an obnoxious manner by an obnoxious person.

Re: Hacked: commit to rails master on GitHub

#26

I'm confused. Is this a generic Github vulnerability or is this a vulnerability in tools outside of Github used by Rails? The 'hacker' seems to suggest it's the former ("Github pwned"), which would be pretty serious stuff.

It's a vulnerability in Rails, which is what GitHub is built on. The vulnerability was demonstrated by adding a commit to the Rails project on GitHub, indicating that GitHub suffers from the vulnerability. Here's the relevant issue. It might clarify things a bit better: https://github.com/rails/rails/issues/5228

Well… strictly speaking it's not a vulnerability in that you aren't inherently unsafe just because you use rails.

It is a bug in that it's a usability issue; maybe it should be turned on by default, much like the auto escaping to prevent XSS that came in rails 3.

Re: Hacked: commit to rails master on GitHub

#28
post #3

I'm confused. Is this a generic Github vulnerability or is this a vulnerability in tools outside of Github used by Rails? The 'hacker' seems to suggest it's the former ("Github pwned"), which would be pretty serious stuff.

I think it's a mass assignment vulnerability: https://github.com/rails/rails/issues/5228

If it's a simple mass-assignment vulnerability, the Rails team has nothing to do with it given that mass-assignment is a feature and the vulnerability is well documented:

http://edgeguides.rubyonrails.org/security.html#mass-assignm...

Heck, I even learned this way back when I was learning Rails:

http://railscasts.com/episodes/26-hackers-love-mass-assignme...

Re: Hacked: commit to rails master on GitHub

#29

I'm confused. Is this a generic Github vulnerability or is this a vulnerability in tools outside of Github used by Rails? The 'hacker' seems to suggest it's the former ("Github pwned"), which would be pretty serious stuff.

I think this is related to an issue he opened on Rails[1] which would suggest that GitHub isn't protecting against malicious mass assignment.

By default, if you have an new, create or update_attributes (and more, I imagine) call which changes various attributes based on a hash from parameters (eg params[:post], where you have params[:post][:title], params[:post][:body] etc) Rails allows mass assignment of every attribute on that model, since attr_accessible is not called.

There is a method you can call in the model called attr_accessible that restricts the columns that can be updated through mass assignment, while still allowing for manual assignment of other columns.

An example of this might be a post's user_id, which you would usually want to set to the current user while not allowing mass assignment. Without specifying attr_accessible it would mean that if a malicious user added params[:post][:user_id] to their POST/PUT, the Rails application would update the user_id as per the params value. If attr_accessible had been called, defining the columns that the developer wanted to be mass assigned (say post and title), it would mean that the user_id would not be mass assigned and Rails would log that this was the case.

attr_accessible therefore acts as a whitelist for columns that can be mass assigned. It just so happens that the Rails default is to have no whitelist and allow all columns to be mass assigned, despite the fact that the sensible option is to always have a call to attr_accessible in your models.

[1]: https://github.com/rails/rails/issues/5228

Re: Hacked: commit to rails master on GitHub

#30
post #21
post #9

Earlier quoted context omitted.

He registered a commit using his own account - so he either got the password of a rails admin or he must've found a way to add his keys to the rails github account directly. The comments on the commit mention he just raised an issue that few people protect the attributes on their models from mass assignment, which… is one way this could happen. Kind of a dick move, though. Responsible disclosure, doing it on a Sunday…

> Responsible disclosure If you look at the bug report, the core Rails Dev Team basically said that they like the defaults the way that they are. They have/had no intention of changing the defaults, and are trying to push responsibility on to the developers using Rails to use sane config settings. Looks like the guy did report it and the response was: "Not our problem" / "Not an issue." He got frustrated and decided…

Rails bugtracker != notifying the people at github that they forgot to add a mass-assign protection.
Post reply on HN