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

211–220 of 240 posts

Re: Hacked: commit to rails master on GitHub

#211

Post by soveran »

wycats wrote: post #65
bradly wrote: 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…

> 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 is not easy to quickly fix heavily.

It can be argued that those apps were already broken. Nobody should complain against a security fix.

Re: Hacked: commit to rails master on GitHub

#212

Post by hemancuso »

ceejayoz wrote: post #109
teej wrote: post #95

Posting it as an issue on the Rails repo and then exploiting GitHub with it is a great way to get attention, but not necessarily the most responsible. I disclosed a vulnerability to GitHub before. I dropped it into their Issues system marked private with the heading "URGENT". It was a Sunday and I got a response + a fix from Tom Preston-Wener himself within a few hours. That, in my mind, would have been a more respon…

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.

The users who trust Github don't care if it was a "rails issue" or a "github issue"

It's a Github issue no matter what the cause or responsible party.

If Github was run on unpatched windows XP boxes with all IPs public, you wouldn't argue that it was Microsoft's fault because "everyone knows" what a bad idea that would be. The base assumption should not to be completely reliant on your environment and frameworks to be secure, because they very likely have un-patched bugs and exploits. You do what you can to harden yourself up, but when something goes wrong - it's your problem.

Re: Hacked: commit to rails master on GitHub

#213

Post by psquid »

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.

Re: Hacked: commit to rails master on GitHub

#214

Post by white_devil »

mojombo wrote: post #112

I have written a blog post outlining the exploit and our mitigation procedure: https://github.com/blog/1068-public-key-security-vulnerabili...

So you're actually proud of writing that sleazy piece of damage-control distraction bullshit?

You're completely misrepresenting what happened. Someone pointed out that Rails makes all Rails applications astoundingly insecure by default since forever, and got condescendingly dismissed several times by the people in charge.

He then proceeded to make a point by demonstrating the severity of the security flaw, and you made him look like some malicious hacker that got swiftly punished by the ever-vigilant GitHub team.

Public Key Security Vulnerability, really? You detected the attack and expunged the unauthorized key? What a load of bullshit.

Re: Hacked: commit to rails master on GitHub

#215

Post by tlogan »

Can somebody explain why this is a Rails bug?

Meaning using mass assignment is very similar to SQL injection: you pass variables from user input directly to model without even verifying them. Duh?

Now regarding GitHub: yes there is a security hole and they fixed it.

However, hacking a site after finding its vulnerability is definitely illegal and hope there will be consequences. And he did not even report a problem to GitHub.

Re: Hacked: commit to rails master on GitHub

#216

Post by tlogan »

wycats wrote: post #44

Here's my proposal for improving the situation: https://gist.github.com/1974187 Merb's approach was to have mass assignment protection in the controller, and I personally think it's self-evident that it belongs there. Moving it into the controller will also make it easier to solve the tension between reducing the friction of getting up and running quickly and having good security defaults. In general, Rails' conventi…

Maybe the right proposal is just to disable mass assignment by default? Meaning there is already white listing functionality - always specify attributes you want to save.

Re: Hacked: commit to rails master on GitHub

#217

Post by teyc »

tlogan wrote: post #215

Can somebody explain why this is a Rails bug? Meaning using mass assignment is very similar to SQL injection: you pass variables from user input directly to model without even verifying them. Duh? Now regarding GitHub: yes there is a security hole and they fixed it. However, hacking a site after finding its vulnerability is definitely illegal and hope there will be consequences. And he did not even report a problem t…

    Can somebody explain why this is a Rails bug?
Insecure by default. Microsoft used to be the laughing stock because the default install was vulnerable to exploits. While one might argue that Github devs should have known better, the counterargument is that if Github devs couldn't get it right, think about the thousands of people trying out rails for the first time, building their little web app.

Re: Hacked: commit to rails master on GitHub

#218

Post by teyc »

mojombo wrote: post #112

I have written a blog post outlining the exploit and our mitigation procedure: https://github.com/blog/1068-public-key-security-vulnerabili...

Until proven otherwise, all code hosted on GitHub must be assumed tainted, where potential 0-day has been inserted.

You should consider revealing a history of all public key changes for each project (assuming you still retained apache logs) so that people can decide for themselves how much work they have ahead of them to re-audit their past commits.

Re: Hacked: commit to rails master on GitHub

#219

Post by teyc »

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 ),…

These issues need to be nipped very early on before they get too big to handle. Microsoft was stuck in this situation for many years because they had decided to favour compatibility over security. Rails now has a wide footprint on the web, and it all makes it even more important to enable it to be properly locked down.

I hope this marks a turning point in the way the Rails team think about security.

ps At least Rails no longer allows web crawlers to delete resources by issuing GET requests.

Re: Hacked: commit to rails master on GitHub

#220

Post by einhverfr »

sirclueless wrote: post #157
bascule wrote: post #151

Earlier quoted context omitted.

Ensuring input is properly validated is always the developer's concern. A framework can make that easier for you, but especially in cases like this, which are basic user authentication concerns, it is ABSOLUTELY the developer's responsibility to be 100% sure how all of those abstractions work and ensure there are no leaks anywhere. You can't punt on security. Abstractions may make it easier, but you better be damn ce…

That said, when your tools generate an insecure scaffold by default with no easy path to discovery on how to fix it, your tools do have a security flaw as well. You can't expect all of the developers in the world to be literate in security, especially the ones who choose batteries-included web frameworks as their go-to.

Agreed. Once we got the SQL-Ledger codebase somewhat stabilized security-wise in LedgerSMB, we started removing it in favor of a secure-by-default framework. Our approach might not work well for other projects and it has its own security pitfalls (which we clearly document, and prevent by default), namely the fact that credential reuse is important and therefore you have to do something like HTTP-BASIC or HTTP-KRB5 auth (and hence for the former SSL really is required).

The way we do it is by not trusting the application. All authorization happens by levels further back, such as permissions granted to run stored procedures or on relations (permissions are granted to relations where there really is a clear, coterminous mapping between relational operations and procedural ones).

We then provide a framework for handling all of this. It means that as-yet-undiscovered flaws in our application are not as exploitable as they might be because the app is not trusted by the database.

Post reply on HN