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

Github Is Classy

jtimberman.housepub.org

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Github Is Classy

#61

Post by envex »

nivloc wrote: post #21
kenneth_reitz wrote: post #3

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.

How did they do a bad job?

They (temporarily) disabled the account, fixed the problem and re-enabled the account. All while keeping people in the loop about what happened......at 9am............on a sunday.

I may be wrong, but that seems like a pretty reasonable way of handling the situation.

Re: Github Is Classy

#62

Post by smackay »

raganwald wrote: post #5

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 short excerpt from the Hitchhikers Guide to the Galaxy seems appropriate:

“`...You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.' `But the plans were on display...' `On display? I eventually had to go down to the cellar to find them.' `That's the display department.' `With a torch.' `Ah, well the lights had probably gone.' `So had the stairs.' `But look you found the notice didn't you?' `Yes,' said Arthur, `yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ”Beware of The Leopard".'"

Re: Github Is Classy

#63

Post by raganwald »

javascriptlol wrote: post #37
raganwald wrote: post #35

Earlier quoted context omitted.

I don’t think you should try to rephrase my words in your words, because in doing so you are completely misrepresenting what I said. So please, stick to just reading my words, and if you want to disagree with what I actually write, do that. What I said was: If you want to say that you disagree with the choice as it was originally made, I agree with that too. Meaning, I disagree with the design. At no time did I say t…

I'm not interested in your sophistry. You're saying it is not a vulnerability in rails, on the basis that it can be fixed by users. That's tantamount to justifying it, regardless of the degree. Rails is dead wrong here and I'm not interested in playing the "try to be right on the Internet" game with you.

  I'm not interested in playing the "try to be right on the Internet" game with you.
Just as well, it seems that we agree on so much that focusing on where we are saying different things devolves into pedantry precisely because we agree on the important matters.

As I said elsewhere:

We probably agree that this feature should be taken out and shot, but are quibbling over which charge should be read off the indictment before giving the order to fire ;-)

Re: Github Is Classy

#64

Post by generalk »

raganwald wrote: post #5

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?
Yes, if you never ever call `update_attributes` you're not vulnerable. This is, however, the most common way to perform model updates.

  > And likewise, for people who RTFM before using mass 
  > assignment, their applications are not vulnerable, 
  > correct?
No! Absolutely not! The Github exploit is a prime example of this. Solid developers, who have obviously ReadTFM, can easily fall victim to this because the default is to be insecure!

The fact is that Rails ships code generators that give you insecure code and put the onus on you to do something about it.

I'm not absolving any developer of their responsibility to not shoot themselves in the foot. Ultimately, if this Github exploit had been used to do serious damage, Github, not the Rails core team, would have been responsible. It is the developer's responsibility to ensure that their code is as free of vulnerabilities as they can make it.

Re: Github Is Classy

#65

Post by Drbble »

raganwald wrote: post #36
hartror wrote: post #24

Earlier quoted context omitted.

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 underst…

I think we’re in agreement. I don’t like the design, I don’t use it myself. I just think that it’s not correct to say that Rails has a security vulnerability and especially that Rails is vulnerable by default. Both of these expressions carry the false connotation that all rails apps are vulnerable and that the fix for the vulnerability lies in patching Rails, when in actuality Rails has a questionable design problem,…

Scaffolding is part of rails, so fixing the bug does involve patching rails.

"Windows has no security vulnerabilities itself, since you can edit the exe of any malfunctioning app. A security conscious app developer is responsible for auditing Windows and making necessary changes. Heck, most vulnerabilities have already been documented, and sometimes the workaround doesn't even involve coding. " See how silly that is?

Re: Github Is Classy

#66

Post by thenduks »

ryanbrunner wrote: post #55
thenduks wrote: post #13

Earlier quoted context omitted.

On one hand you have `update_attributes` - IMO you should just never use this (seems raganwald agrees), but hey, it exists and it can be useful for simple stuff. So on the other hand is `attr_accessible` - You need to specify what is allowed to be mass-assigned if you want to use mass-assignment. This stuff is covered in the basic Rails Guides ( http://guides.rubyonrails.org/security.html#mass-assignment ). Saying th…

Pretty much every tutorial I can find on using controllers in Rails uses mass assignment, and the majority of them (including the beginners guide on guides.rubyonrails.org) don't mention attr_accessible or the security risk in allowing unrestricted mass assignment. We're telling people to RTFM, but the FM doesn't say a thing about how this is dangerous. If it was considered standard to avoid use of your brakes at all…

It may not be mentioned in the beginner docs... I feel ok insisting that professional software developers read more than an intro to the framework they are using.

Also not mentioning it isn't the same as avoiding it 'at all costs'.

To continue the analogy: Sales person says "Look how fast this Ferrari can go!", then later, in the manual, "Drive at a responsible speed given your local laws, etc."

All that said I do actually think that changing the default to be more annoying and more safe is a good thing (and it's been done https://github.com/rails/rails/commit/06a3a8a458e70c1b6531ac...). Just saying that I agree with raganwald -- this isn't even close to a 'security vulnerability'.

Re: Github Is Classy

#67

Post by Drbble »

jacques_chester wrote: post #16
raganwald wrote: post #5

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…

Thank you! "policy vs mechanism" popped into my head when this debate for going, but I didn't write it up well like the above post did.

Re: Github Is Classy

#68

Post by chives »

envex wrote: post #61
nivloc wrote: post #21

Earlier quoted context omitted.

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.

How did they do a bad job? They (temporarily) disabled the account, fixed the problem and re-enabled the account. All while keeping people in the loop about what happened......at 9am............on a sunday. I may be wrong, but that seems like a pretty reasonable way of handling the situation.

You are told that your back door was open 3 months ago. You "investigate" then tell the witness they are mistaken, the back door is closed. 3 days later the witness walks through the back door which has been open for 3+ months and shits in your fridge. You suspend his account and write an inflammatory post about the guy for has been telling you for 3 months that your back door was open. He could have walked in and burned your house down, shredded your reputation, and caused every paying developer you have to jump ship. He didn't.

GitHub has handled this situation in the worst possible way, from start to finish. Thank god an ethical hacker shit in their fridge. The alternative is frankly unimaginably bad for the whole community.

Re: Github Is Classy

#69

Post by envex »

chives wrote: post #68
envex wrote: post #61

Earlier quoted context omitted.

How did they do a bad job? They (temporarily) disabled the account, fixed the problem and re-enabled the account. All while keeping people in the loop about what happened......at 9am............on a sunday. I may be wrong, but that seems like a pretty reasonable way of handling the situation.

You are told that your back door was open 3 months ago. You "investigate" then tell the witness they are mistaken, the back door is closed. 3 days later the witness walks through the back door which has been open for 3+ months and shits in your fridge. You suspend his account and write an inflammatory post about the guy for has been telling you for 3 months that your back door was open. He could have walked in and bu…

Did he actually contact GitHub directly?

Didn't he just post issues/comment on the issue in rails/rails?

Re: Github Is Classy

#70

Post by kenneth_reitz »

envex wrote: post #69
chives wrote: post #68

Earlier quoted context omitted.

You are told that your back door was open 3 months ago. You "investigate" then tell the witness they are mistaken, the back door is closed. 3 days later the witness walks through the back door which has been open for 3+ months and shits in your fridge. You suspend his account and write an inflammatory post about the guy for has been telling you for 3 months that your back door was open. He could have walked in and bu…

Did he actually contact GitHub directly? Didn't he just post issues/comment on the issue in rails/rails?

That was my understanding as well. @chives, can you elaborate?
Post reply on HN