Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacked: commit to rails master on GitHub

github.com

Post reply on HN
Print view View original

221–230 of 240 posts

Re: Hacked: commit to rails master on GitHub

#221

Post by GrumpySimon »

rsynnott wrote: post #155
ceejayoz wrote: post #109

Earlier quoted context omitted.

The point, though, is that this is more of a Rails issue than a Github issue. If Github gets it wrong, others are likely to.

Well, it's a beginner-level Rails mistake; it is not precisely an obscure issue. Googling 'attr_accessible' will show you discussion going back years, and it has been actively exploited before. I'm shocked that the mistake was made in Github, though.

Allow me to rephrase that:

"Well, it's a beginner-level PHP mistake; it is not precisely an obscure issue. Googling 'SQL Injection/register_globals/get_magic_quotes/etc' will show you discussion going back years, and it has been actively exploited before. I'm shocked that the mistake was made in ..., though."

Ten+ years of register_globals, get_magic_quotes and SQL injection attacks (etc etc etc) in PHP show that even well-known issues still bite people everyday. IMO, it's up to the framework developers to make it easy to do the right thing and damn hard to do the wrong thing.

Re: Hacked: commit to rails master on GitHub

#222

Post by bryanbibat »

marshray wrote: post #128
vidarh wrote: post #55

Earlier quoted context omitted.

The fact that this is even a discussion is sufficient for me to consider it a bug. It's irresponsible of the Rails team to leave this default the way it is given that it's long been a known risk. That they like to consider it a "feature" doesn't make it any better - it just makes them look like idiots

I was going to say the same thing. The Security guide does describe the issue, and even describes attr_accessible as a "Countermeasure". http://guides.rubyonrails.org/security.html#mass-assignment Without any precautions Model.new(params[:model]) allows attackers to set any database column’s value. Unbelieveable! PHP showed long ago that allowing a web request to auto-populate arbitrary members in app objects is just…

Er.. that's because there's nothing malicious an attacker can do with the mass-assignment vulnerability in the "Hello Rails" app?

Being able to change the :id or timestamps of the post isn't anywhere near the SQL injection vulnerabilities I've seen in many tutorials in other languages/frameworks.

I agree, though, I wouldn't recommend Rails to people who can't bother to read documentation.

Re: Hacked: commit to rails master on GitHub

#223

Post by docwhat »

wycats wrote: post #178
tylermenezes wrote: post #163

Earlier quoted context omitted.

First he submitted a bug, and they closed it. Then, he reopened the bug to prove it was a bug, and they closed it again. Then, he submitted a new bug, 1001 years in the future, and they closed it, saying "Good one ;)" Then, he committed a text document to master, and they got all upset about it and got Github staff involved. How about this Ruby devs: actually consider what you're saying. Isn't the point of Ruby to ma…

Not all security vulnerabilities can be protected automatically by a web framework. In many cases, frameworks provide features that developers can use themselves to secure their applications. Example: XSS is a common web security problem. In short, it means that putting user-originated data back on the page unescaped is unacceptable. Before Rails 3.0, the Rails approach to this problem was to provide a helper ( h ),…

I don't like the suggestion. It enforces a 1:1 relationship between controller and model.

I'd rather have the model and the ORM be pulled apart and the model make this distinction.

Or create another class that knows how to safely pull values out of a params list and use it to create a model.

But it's bad enough that the controllers "look" like they belong to a model in default Rails generators. This creates a certain amount of laxity in programmer's thinking. It boxes their thinking in instead of letting their thinking go free.

Re: Hacked: commit to rails master on GitHub

#224

Post by wasabideveloper »

wycats wrote: post #178
tylermenezes wrote: post #163

Earlier quoted context omitted.

First he submitted a bug, and they closed it. Then, he reopened the bug to prove it was a bug, and they closed it again. Then, he submitted a new bug, 1001 years in the future, and they closed it, saying "Good one ;)" Then, he committed a text document to master, and they got all upset about it and got Github staff involved. How about this Ruby devs: actually consider what you're saying. Isn't the point of Ruby to ma…

Not all security vulnerabilities can be protected automatically by a web framework. In many cases, frameworks provide features that developers can use themselves to secure their applications. Example: XSS is a common web security problem. In short, it means that putting user-originated data back on the page unescaped is unacceptable. Before Rails 3.0, the Rails approach to this problem was to provide a helper ( h ),…

@wycats any chance of you creating a screencast of how to tackle Rails security from your experience with Merb/Rails?

Thanks again for your hard work and being a public voice on the issue.

Re: Hacked: commit to rails master on GitHub

#225

Post by mofey »

mofey wrote: post #185
vvnraman wrote: post #140

Earlier quoted context omitted.

I don't think he can be blamed too much though. As per the bug filed here - https://github.com/rails/rails/issues/5228 , the bug was being closed by others after being given a cursory look, and was being reopened again for consideration. Maybe a little immature, but there was a mild provocation.

Hey, how come there are no comments by @dhh and @josevalim? Are we missing out on epicness of zedshaw-level?

  Fred Wu
  So what's a good gem (if any) for safe guarding params on the controller level? @dhh's params.slice feels too dirty.
  DHH ‏
  yeah, it's too simple to be clean! I think you are using the wrong framework if you crave more complexity for its own sake.

Re: Hacked: commit to rails master on GitHub

#226

Post by Ecio78 »

bgentry wrote: post #56
holman wrote: post #33

We've patched and fixed this on GitHub.

Do you plan on notifying customers whose repos he accessed? This looks like more than just a minor breach if he was able to give himself admin rights and had read/write access to any repo.

Actually the problem is not which repos he accessed (they can easily determined by looking at their logs), the problem is if/how_many other repos have been accessed by blackhats who knew this exploit before, and what kind of commit they've done to all these projects.

Re: Hacked: commit to rails master on GitHub

#227

Post by nailer »

rsynnott wrote: post #155
ceejayoz wrote: post #109

Earlier quoted context omitted.

The point, though, is that this is more of a Rails issue than a Github issue. If Github gets it wrong, others are likely to.

Well, it's a beginner-level Rails mistake; it is not precisely an obscure issue. Googling 'attr_accessible' will show you discussion going back years, and it has been actively exploited before. I'm shocked that the mistake was made in Github, though.

My understanding is that it's an insecure built-in default. Ie, the mistake is by the Rails framework developers, and Rails users have to explicitly secure it. Is that incorrect?

Re: Hacked: commit to rails master on GitHub

#228

Post by nailer »

angersock wrote: post #176
grabastic wrote: post #162

Earlier quoted context omitted.

"Hey customer, someone hacked your page thanks to a vulnerability in my service, but don't worry... I've added him as a contributor to my project and sent him a thank you email." Like that?

More like: "Dear Grabastic, Today we had a demonstration by a user (xxx) of a security vulnerability on our site. ${VULNERABILITY_EXPLANATION} We believe that it is possible that your application or records are covered in the scope of the exploit, because of the fact that ${VULNERABILITY_APPLICATION}. In order to fix this issue, we have ${VULNERABILITY_PATCH}. We have thanked this user for their vigilance in spotting…

What if the customer is panicing, because the message looked like:

+another showcase of rails apps vunlerability. 2 +Github pwned. again :( 3 +will you pay me for security audit?

It kinda sounds like you've succumbed to an extortion demand.

Re: Hacked: commit to rails master on GitHub

#229

Post by Joeboy »

nwmcsween wrote: post #170
tylermenezes wrote: post #163

Earlier quoted context omitted.

First he submitted a bug, and they closed it. Then, he reopened the bug to prove it was a bug, and they closed it again. Then, he submitted a new bug, 1001 years in the future, and they closed it, saying "Good one ;)" Then, he committed a text document to master, and they got all upset about it and got Github staff involved. How about this Ruby devs: actually consider what you're saying. Isn't the point of Ruby to ma…

"This is why I refuse to learn Ruby. I don't want to be associated with that community. "Learn Ruby if you want to be associated with a bunch of people who call themselves Rockstar Programmers."" You refuse to learn a language due to how a project acts? Have you ever read the {open,free,net}BSD or Linux mailing lists? You're not going to make it far in software development with an attitude like that.

I'm not intimate with the Ruby community, but the quality / quantity / culture of the community surrounding a programming language seems like a reasonable consideration to me.

Re: Hacked: commit to rails master on GitHub

#230

Post by muyuu »

psquid wrote: post #213
orblivion wrote: post #113

> "Since you can commit to master, you could just fix the vulnerability :) " I like it, this would be a great way to be snarky and semi-responsible at the same time.

Yeah, it seems to me that committing a fix with a commit message along the lines of "Oops, you left this open. Don't worry, though, I fixed it." would've been the best option.

Technically it would be more like: "I just set it to safer defaults, since you guys won't. By the way, if your defaults are not strict enough for Github - where you trusted to host your code - gets them right, that pretty much makes them unsafe defaults."
Post reply on HN