Hacker News Reader

Comment by zyfo | Hacker News Reader

Here's the guy's blog post about the hack: http://homakov.blogspot.com/2012/03/egor-stop-hacking-gh.htm...

"Today I can pull/commit/push in any repository on github. Jack pot."

Regardless of the 'hacker's motives/personality, I think this is yet another testimony to the power of open source.

When you have this many eyeballs looking at your code, the odds of a good-intentioned (however playful/immature) coder to discover a vulnerability is much greater than those of a real ill-intentioned hacker simply due to the sheer number of the former. The issue will quickly get fixed by the community, the kid will get the attention he wants, and life will go on.

Hmm? The vulnerability is in github's code (not open source) and not in rails.

It actually looks like the vulnerability is on Rails itself, which Github is built on...

The vulnerability is that Rails is insecure by default. That used to be the case for a lot of things, then finally people noticed how the real world works, and started fixing them. Apparently the Rails developers have actively resisted the lesson everyone else already learned.

The vulnerability is still Github's. Rails provide the tools to do this right. Whether rails should provide stricter defaults is another question altogether.

I was replying to the parent, who attributed this to the power of "open source & eyeballs looking at your code" but this is not such an instance.

Lots of projects provided the tools to do lots of things right in years past, but they eventually came to recognize that if they didn't provide secure defaults, they were ultimately harming everyone out of some twisted sense of principle. Insecure defaults are thus now considered a vulnerability in the original project.

This was not a case of "Rails is insecure by default".

There's very popular idiom in Rails development of updating model data from a form POST/PUT in one line of code in a controller:

my_object.update_attributes(params[:object])

Because many users follow this approach, it made this hack widely exploitable. You can either assign parameters piecemeal in the controller or explicitly set the attr_accessible attributes in the model. There's nothing inherent in Rails that caused this vulnerability, rather it was programming practices by developers.

There's a fine line between (1) "insecure by default" and (2) the existence of a very popular idiom that is dangerous unless accompanied by other checks.

Many PHP apps used to rely on register_globals without proper input checking, and when those apps got hacked, it was clearly their their own fault. Just like GitHub is primarily responsible for today's exploit. But that didn't prevent people from calling PHP "insecure by default" for enabling register_globals in the first place.

Reply on news.ycombinator.com