Live data from Hacker News

Hacked: commit to rails master on GitHub

github.com

71–80 of 240 posts

Re: Hacked: commit to rails master on GitHub

#71
post #65
post #60

Earlier quoted context omitted.

> Merb's approach was to have mass assignment protection in the controller, and I personally think it's self-evident that it belongs there. But wasn't Merb merged into Rails? :) Sigh...

Not every idea from Merb made it into Rails. Especially when an idea would cause significant backwards-compatibility breakage (return string from action vs. implicit rendering), we stuck with the Rails approach. I always felt that "it's up to the developer to do the right thing" violates the normal Rails convention over configuration principles, but I also weigh breaking a large % of existing Rails apps in a way that…

Yes, the way Merb handled controllers was one of places it really shined over Rails. Hopefully over time more and more of these ideas will make their way back into to Rails.

Re: Hacked: commit to rails master on GitHub

#72
post #33

We've patched and fixed this on GitHub.

For reference, it's easy to determine if a Rails application is vulnerable to mass assignment attacks by attempting to set an attribute that is unlikely to exist (e.g., user[asdfg]). In the majority of cases a 500 error will be returned if the application is vulnerable.

Re: Hacked: commit to rails master on GitHub

#73
post #62

Earlier quoted context omitted.

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

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.

Re: Hacked: commit to rails master on GitHub

#74
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.

So? He didn't do anything wrong that we know of, he just used the available api from github. Unless "messing with an open-source project" has become a crime...

Re: Hacked: commit to rails master on GitHub

#75
post #24
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…

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.

My thoughts exactly: the "asshole" is 18. People should give him a break already, and consider we're lucky he's getting the word out.

Re: Hacked: commit to rails master on GitHub

#76
post #49

Earlier quoted context omitted.

Time from exploit to fix in production: I'd buy Github stock if I could.

It doesn't hurt that the vulnerability was already discussed in a bug report by the 'attacker.' I'd imagine it would have taken a longer time had they needed to track down how exactly this happened, though I guess I'm making an assumption on what their logging/auditing/reporting is like.

Right, I'm kind of baffled by the posters on the bug report calling this a "0-day" exploit.

Re: Hacked: commit to rails master on GitHub

#77
post #66
post #33

We've patched and fixed this on GitHub.

As a paying customer, whose sole reason in paying you is to keep his data secure, I expect a bit more than "we fixed it" ... details please.

It's a lot quicker to publicize a vulnerability than it is to patch, ascertain the scope, and verify the current situation. We're taking the time to make sure the information we'll relay to you is accurate.

Re: Hacked: commit to rails master on GitHub

#78
post #15

Earlier quoted context omitted.

He submitted it to… the rails bug tracker. Three days ago. That's not disclosing the issue to GitHub at all .

It's a pretty insane leap of logic to maliciously attack the Github website to prove your point regarding a framework hosted on that website. Politely contacting people about the vulnerability, rather than pulling that crap in an extremely public venue seems like the more mature, and less incredibly illegal way to go about things.

The "attack" clearly wasn't malicious, though probably immature. A malicious attacker would have been doing things like gaining access to users' private repos and stealing the code, or trying to sneak in harmful commits to a repo under a false name. This was at most a prank or a demonstration. So why this instead of responsible disclosure?

The problem is that it was not really a GitHub issue, it's Rails having a grossly insecure default setting. According to one of the comments in the bug tracker a lot of other high-profile sites also have the same problem. And presumably new ones would keep popping up for as long as Rails is the new hotness.

So disclosing the problem to GitHub would not solve anything. They'd deploy the fix, but a lot of other sites remain vulnerable. That's probably the case even if GitHub were willing to take a PR hit and admit they'd been insecure for a long time in order to spur other Rails users to fix their code. After all, they hadn't fixed their code after the previous widely published security problems caused by the same underlying issue.

Clearly the Rails core team were not willing to consider any kind of changes to improve the situation. As such, you can argue that making as big a scene as possible is the best way to improve security globally. It's of course unfortunate for GitHub that he chose to use that site as the example due to the obvious reasons. And certainly the timing is about as unfriendly as possible from the point of view of a west coast person.

Re: Hacked: commit to rails master on GitHub

#79
post #62

Earlier quoted context omitted.

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.
Post reply on HN