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

31–40 of 85 posts

Re: Responsible Disclosure Policy

#31

Post by georgemcbay »

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 community might never have realized the lurking horror that the Rails team appears to have been unlikely to do anything about other than point people to the existing docs.

This situation shows that pointing people to those docs was clearly an inadequate solution. If GitHub (arguably the poster child for Rails apps outside of 37signal's own apps) could fuck this up, anyone using Rails could. All of this exposure to the problem is net positive for everyone using Rails other than GitHub and the core Rails team, IMO.

Re: Responsible Disclosure Policy

#32

Post by rflrob »

gbrindisi wrote: post #5

I hate to be the one pointing out this but it's a shame that a company like GitHub will reward responsible disclosures just with a thank you and the promise to not pursue a legal action. http://help.github.com/responsible-disclosure/ "white hat researchers are always appreciated"

If what you're implying here is that they should be offering a bounty for discovery of bugs, I'm not necessarily disagreeing with you, but to expect them to get a policy about that and to allocate funding for those bounties on a Sunday, within 24 hours of a major, public breach seems a little unreasonable.

Re: Responsible Disclosure Policy

#33

Post by antris »

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…

I see this whole story as "Irresponsible kid accidentally teaches the whole town a lesson"

Re: Responsible Disclosure Policy

#34

Post by Lazare »

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…

I agree with you up to a point; those certainly should be their priorities. However, suspending his account didn't help them accomplish any of those goals.

I think we can all agree that it certainly didn't help them fix the vulnerability or communicate with users, right? (Actually, it arguably did the reverse...) But it also did absolutely nothing to stop him from breaking into the service; the exploit works for any user, and Github allows anyone to create an account instantly and for free. Until the exploit was fixed, anyone including him could have created an account and exploited their service.

A better defence of Github would be that they couldn't have been expected to know that, and so they shouldn't be slammed for doing something unproductive and pointless that distracted them from the three core priorities you list above. And I agree! If something looks fishy, banning everyone involved, and sorting it out later is actually a pretty decent idea...even if (as here) it proves to be a complete waste of time in retrospect.

Re: Responsible Disclosure Policy

#35

Post by dandelany »

antris wrote: post #33
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…

I see this whole story as "Irresponsible kid accidentally teaches the whole town a lesson"

Irresponsible, perhaps, but somehow I doubt it was accidental :)

Re: Responsible Disclosure Policy

#36

Post by Volpe »

dthunt wrote: post #27

Honestly, I am less likely to want to use github in light of this announcement. You handled this incident badly, and then didn't acknowledge it, nor offer the much-needed props to Egor for exposing an issue you guys didn't think was serious. If this is how you react to someone who WANTS to tell you about a serious problem, how what percentage of the people who don't love you enough to put a tattoo on themselves are l…

He didn't WANT to tell github, he wanted Rails Core to pay attention to him, and github was the sacrificial lamb.

He doesn't deserve props from github, he just exploited their app to make a point (to rails core) he never disclosed anything to github, from what I can tell.

Re: Responsible Disclosure Policy

#37

Post by davyjones »

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…

> Actually, the world _does_ stop turning because it's Sunday.

Incorrect. In Islamic countries, which are a part of this world, like Saudi Arabia and Oman have Thu-Fri weekend.

http://en.wikipedia.org/wiki/Workweek_and_weekend#Islamic_co...

Re: Responsible Disclosure Policy

#38

Post by davesims »

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.

Re: Responsible Disclosure Policy

#39

Post by zzzeek »

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.

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.
Post reply on HN