Live data from Hacker News

Github Is Classy

jtimberman.housepub.org

21–30 of 70 posts

Re: Github Is Classy

#21

The amount of bad press GitHub has received from this has blown me away. If anyone should be getting flamed for this, it should be the Rails maintainers that weren't open to the discussion.

Github left the most widely known gap in Rails security open to exploit. Then they did a bad job handling the fallout.

I'm not saying the Rails devs shouldn't have changed it five (maybe seven now?) years ago when it first came up, but output escaping wasn't default until 3.x, and everyone in the community knew both were major problems.

Re: Github Is Classy

#22

The amount of bad press GitHub has received from this has blown me away. If anyone should be getting flamed for this, it should be the Rails maintainers that weren't open to the discussion.

I respect your work Ken but I disagree with you on this. Rails is just a web framework and does provide developers who use it with the ability to use it securely or insecurely. In this case, the shipped default leaned more toward convenience than security. There are tradeoffs involved. GitHub provides codebase hosting to thousands of projects, some of which are private. They have a large public attack surface. And th…

I respect your work Ken but I disagree with you on this.

I just want to give a huge nod of recognition to this extremely civil way to express disagreement. Bravo!

Re: Github Is Classy

#23
I never said this is a security vulnerability in Rails.

I said it is a bug (and a serious one).

A bug, as you may be aware, is a mistake, fault, failure, problem or other unintended or surprising behavior in software.

See updates to my post for some additional clarification. I hope that helps. Thanks for reading!

Re: Github Is Classy

#24
post #10

Earlier quoted context omitted.

"this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerability in apps written using a certain style, or perhaps a vulnerability by default in apps written using the generators and scaffolding baked into rails." Well, gee...so maybe some novice developers write an app using the generators and scaffolding baked into Rails , and as a result they get a s…

so maybe some novice developers write an app using the generators and scaffolding baked into Rails, and as a result they get a security vulnerability that a more experienced developer might have avoided by doing extra work, and you say that's not a security problem in Rails? Young man, do not take that flippant tone with me (raps ruler on desk). Those novice developers failed to RTFM. If you want a framework that pro…

Scott Meyers (author of Effective C++ et al.) has talked about this subject many times (including in the aformentioned book) and it puts the ball squarely in the Rails team's court.

Let's make the reasonable assumption that your clients—the people using your interfaces— are trying to do a good job. They're smart, they're motivated, they're conscientious. They're willing to read some documentation to help them understand the system they're using. They want things to behave correctly.

That being the case, if they make a mistake when using your interface, it's your fault. We're assuming they're doing their best—they want to succeed. If they fail, it's because you let them. So, if somebody uses your interface incorrectly, either they're working hard at it (less likely) or your interface allowed them to do something easy that was not correct (more likely). This puts the shoe on the foot not used to wearing it: it means that responsibility for interface usage errors belongs to the interface designer, not the interface user.

Source: Scott Meyers: The Most Important Design Guideline? http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_rev...

Re: Github Is Classy

#25

Perhaps I am misunderstanding the situation. Am I correct that the so-called “vulnerability” is that if you do a mass assignment from an untrusted source—form parameters—to a model without whitelisting attributes via attr_accessible, an attacker can write values to arbitrary attributes? If so, this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerabil…

You confusing mechanism and policy . Sure, Rails includes a mechanism that closes this security hole. But it requires additional effort to apply a more secure policy . The security baseline is not elevated by the mechanism. Historical experience has shown that no matter how excellent the mechanism, the practical security baseline is determined by the default policy. Windows NT has had, since inception, a far more sop…

The funny thing is that Windows 95 was released AFTER Windows NT.

Re: Github Is Classy

#26

Perhaps I am misunderstanding the situation. Am I correct that the so-called “vulnerability” is that if you do a mass assignment from an untrusted source—form parameters—to a model without whitelisting attributes via attr_accessible, an attacker can write values to arbitrary attributes? If so, this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerabil…

>And likewise, for people who RTFM before using mass assignment, their applications are not vulnerable, correct?

Brilliant point. While we're all talking about this issue, lets all team up, all of us here on HN, right now, to email php-internals and ask them to bring back register_globals and turn it on by default. It was a mistake on their part to disable it. After all, who doesn't read and follow all the documentation?

Re: Github Is Classy

#27

I never said this is a security vulnerability in Rails. I said it is a bug (and a serious one). A bug, as you may be aware, is a mistake, fault, failure, problem or other unintended or surprising behavior in software. See updates to my post for some additional clarification. I hope that helps. Thanks for reading!

"The same user exploited another vulnerability". It wasn't exactly "another vulnerability". It still had to do with the same mass attribute assignment feature just in a different place.

Re: Github Is Classy

#28
post #12
post #2

I really think the actual issue here has been clouded over by reactions to the way the issue was handled. Sure it wasn't the most mature and professional way of handling the situation, it was illegal and he certainly didn't need to take it to the extent he did - but he put the issue to the forefront. Github responded well although it does seem as they were trying to spin it as though they had the situation in hand mo…

The problem is people are still confusing two issues. 1 - The mass assignment rails issue was resolved as soon as could be after it was reported 2 - The public key form update vuln was NOT reported and used, NOT to attack github but to make some point to the Rails team. The second issue was the one github had been talking about in the original blog post. They handled it as soon as it was discovered. In so far as they…

The public key form update vulnerability was based on the same concept in a different place.

Re: Github Is Classy

#29
post #10

Perhaps I am misunderstanding the situation. Am I correct that the so-called “vulnerability” is that if you do a mass assignment from an untrusted source—form parameters—to a model without whitelisting attributes via attr_accessible, an attacker can write values to arbitrary attributes? If so, this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerabil…

"this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerability in apps written using a certain style, or perhaps a vulnerability by default in apps written using the generators and scaffolding baked into rails." Well, gee...so maybe some novice developers write an app using the generators and scaffolding baked into Rails , and as a result they get a s…

sounds like pointers in C vs C++

Re: Github Is Classy

#30

Perhaps I am misunderstanding the situation. Am I correct that the so-called “vulnerability” is that if you do a mass assignment from an untrusted source—form parameters—to a model without whitelisting attributes via attr_accessible, an attacker can write values to arbitrary attributes? If so, this isn’t a security vulnerability in Rails. A new Rails application isn’t vulnerable by default. It’s a security vulnerabil…

But for guys like me who never use mass assignment, our applications are not vulnerable by default, correct? And likewise, for people who RTFM before using mass assignment, their applications are not vulnerable, correct? If I understand this, it is very different from something like the routes vulnerability a while back, where EVERY Rails app was vulnerable whether you liked it or not. Saying Rails has a security vulnerability here is like saying that ActiveRecord has a SQL Injection vulnerability because by default, find_by_sql allows you to compose queries out of strings, and if you don’t choose to use the correct form, you will be attacked by little bobby tables.

I believe this is absolutely correct.

Post reply on HN