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

Responsible Disclosure Policy

github.com

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Responsible Disclosure Policy

#41

Post by bmj »

freehunter wrote: post #30
stanleydrew wrote: post #24

Earlier quoted context omitted.

That is irrelevant. The world doesn't stop turning on the weekend. It was in Github's best interests to get out ahead of this, and they did. They don't need to be commended for it just because it's Sunday.

Actually, the world _does_ stop turning because it's Sunday. Anything happening on the weekend is emergency management, which takes time to scramble. I work in network/information security, and if we had a security incident on a Sunday, it would go to our backup team (of one). If they (he) deemed it critical, they would notify the security director, who would notify my boss, who would notify the rest of the team. Thi…

I agree. But we're talking about software as a service here, and that kinda makes it a different ballgame. Folks are paying money (in some cases) to use your software living on your servers (or, at least servers that you manage). I would certainly hope that someone who can deal with outages or penetrations is actually working on the weekend (perhaps that person doesn't work Monday and Tuesday?).

Would you say "eh, but it was the weekend" if an attacker purged your paid enterprise repo on a Sunday morning?

Re: Responsible Disclosure Policy

#42

Post by joedev »

Another in the long line of Silicon Valley companies screwing up and then getting kudos from the community for handling the screw up. It's getting tiresome to see people get accolades for basically doing their job, after failing to do their job.

Re: Responsible Disclosure Policy

#44

Post by prophetjohn »

georgemcbay wrote: post #31

Speaking as someone who isn't a Rails developer (but does use GitHub Enterprise for work projects), when this first broke I was on the side of github and thought homakov was acting irresponsibly. Now that more background is coming out, I think he probably did the Rails community at large a huge favor here. Had this just been fixed quietly on GitHub, that would certainly be better for GitHub's PR but the wider communi…

It's not like this is a little known pitfall with Rails. Anyone who has read Hartl's Rails tutorial knows about it[1]. It's very commonly mentioned in basics for Rails security.

And I say all this someone who has never professionally developed for Rails. My experience with Rails consists of a couple half-done toy projects. I find it pretty surprising that Github makes this mistake. But I don't think they should be burned at the stake for this. The bigger problem was how they were initially handling the issue, which they're trying to rectify now.

[1] However, Hartl recommends using attr_accessible at the model level and DHH says this preventative measure should be implemented in the controller, ie:

    class PostsController

Re: Responsible Disclosure Policy

#45

Post by tommorris »

JulianMorrison wrote: post #23

Honestly I have no idea why they didn't just ban him and say "don't hack us". It really should be that simple.

There's a very good reason not to do that. I'm a Wikipedia admin, and we have a policy on blocking and banning that sort of makes sense. A block is done to "prevent damage or disruption". That might be short term or indefinitely, but not permanently. You put in a block when there's an issue. But a ban is a formal statement that you are no longer allowed in. You only do that after some thought and consultation.

Github is actually pretty similar given that the commercial side of Github is fuelled by the free, open-source side. There is a feeling of community ownership. Going straight for the ban without some thought and soul-searching is confusing fixing an issue with making a more detailed judgment about whether the user ought to be on the site at all.

IMHO, Github played it about right.

Re: Responsible Disclosure Policy

#46

Post by icebraining »

philwelch wrote: post #25
JumpCrisscross wrote: post #3

Given that: (1) the nature of the suspension was not communicated to Egor at the onset of the situation, nor, (2) noted in the blog post [1] describing how Github "detected the attack", I am inclined to believe that this is a response to the furious reaction to their suspension decision and was not, as this post implies, the game plan from the beginning. It's healthy that they've reversed their suspension but the lac…

Playing nice with a hacker who just broke into your service shouldn't take priority over: 1. Making sure he doesn't continue breaking into your service (by suspending his account) 2. Fixing the security flaw he used to break into your service 3. Appraising your users to the situation. I feel for the kid--he's just 18, and if he gets some good judgment to go along with his technical skill he'll go far. But I don't und…

How does suspending his account ensure he doesn't continue breaking into your service?

Re: Responsible Disclosure Policy

#47

Post by sneak »

Their claim that his exploiting the vulnerability (in a completely benevolent fashion) was not "responsible disclosure" is bogus.

They need to stop trying to cover their ass and just apologize for suspending the guy.

Re: Responsible Disclosure Policy

#48

Post by michaelbuckbee »

zzzeek wrote: post #39
davesims wrote: post #38

Earlier quoted context omitted.

It's an easy mistake to make, but arguably no easier than, for instance, not escaping input strings to guard against SQL injection. IMO it falls to the developer to set protected on vulnerable attributes. This is pretty basic Rails security practice. EDIT: not 'escaping', but using hashes or formatted strings, etc., you get the idea.

I'm not a Rails/Ruby user but any decent database abstraction layer or ORM should be using bound parameters for all literal values. "Escaping" of SQL strings is best left to the database driver.

You're correct and Rails does do this (handle parameters in such a way as to prevent SQL injection attacks), however it is always possible to circumvent these protections and code things up in such a way (concatenate your own raw SQL string and push it through) as to shoot yourself in the foot.

Re: Responsible Disclosure Policy

#50

Post by jarin »

davesims wrote: post #38
georgemcbay wrote: post #31

Speaking as someone who isn't a Rails developer (but does use GitHub Enterprise for work projects), when this first broke I was on the side of github and thought homakov was acting irresponsibly. Now that more background is coming out, I think he probably did the Rails community at large a huge favor here. Had this just been fixed quietly on GitHub, that would certainly be better for GitHub's PR but the wider communi…

It's an easy mistake to make, but arguably no easier than, for instance, not escaping input strings to guard against SQL injection. IMO it falls to the developer to set protected on vulnerable attributes. This is pretty basic Rails security practice. EDIT: not 'escaping', but using hashes or formatted strings, etc., you get the idea.

This kind of sums up the point of contention.

Rails, by default, does things like escaping input and output strings, CSRF protection, masking password fields in the logs, etc. So why doesn't it do the same with attribute assignment?

Post reply on HN