
Responsible Disclosure Policy - mnilsson
https://github.com/blog/1069-responsible-disclosure-policy
======
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.

~~~
davesims
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.

~~~
zzzeek
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.

~~~
michaelbuckbee
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.

~~~
javascriptlol
Or you could disallow raw SQL strings and always construct programmatically
(e.g. building ASTs). All of these recurring holes are due to bad design,
period. Imagine if your microwave manufacturer said "ultimately it's up to the
consumer to avoid irradiating himself". Nobody expects you to be saved from
sticking a drill into your face, but nor should it electrocute you by
forgetting to do something.

------
JumpCrisscross
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 lack of
transparency (not to mention potential dissembling) on the decision process
regarding the revocation is still troubling.

[1] [https://github.com/blog/1068-public-key-security-
vulnerabili...](https://github.com/blog/1068-public-key-security-
vulnerability-and-mitigation)

~~~
philwelch
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 understand the
nerdrage at Github. People trust Github's service and their software to
protect proprietary code; their response has been everything you could hope
for in the interests of 100%-1 of Github stakeholders, at the expense of not
communicating well to Egor why and how long they were suspending him for
breaking into their service.

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

~~~
timcosgrove
Because it's trivial for him to set up another account and break the service
from there. His ability to do this exploit wasn't tied to his specific
account. His point was that anyone could be doing this.

=edit= Sorry, I am apparently agreeing with the comment I replied to.

------
kragen
The problem I see with this blog post is something I haven't seen mentioned in
the comments. It's not GitHub's place to set policy on what kind of disclosure
is or isn't "responsible". Egor Homakov's responsibility is not to GitHub; his
responsibility is to other users. His moral duty upon finding a security
vulnerability is to act in such a way that other users will be minimally hurt.
It appears that he has fulfilled that responsibility spectacularly in this
case.

GitHub has no business demanding his, or your, agreement to a legal contract
that prohibits you from exercising your best judgment in such a case.

Furthermore, "responsible disclosure" is a propaganda euphemism for "allowing
irresponsible vendors to cover their asses, possibly at the expense of their
users". Terms like "responsible disclosure" have no place in a serious
discussion. Please see the blog post by the Google security team at
[http://googleonlinesecurity.blogspot.com/2010/07/rebooting-r...](http://googleonlinesecurity.blogspot.com/2010/07/rebooting-
responsible-disclosure-focus.html) for further details.

~~~
chalst
This is beautifully put.

------
dthunt
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 likely to report an issue versus sell this to one of
the many buyers of 'sploits who exist out there?

The reality is that these folks generally don't want to hurt you, they just
want you to understand the thing you won't admit. When it happens, and you've
got egg on your face, grow a pair and cop up to the fact that you/the system
failed, and GIVE PROPS. Fix the issue, move on, and award the guy who did you
a solid by finding an issue his 15 minutes of fame.

~~~
Volpe
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.

------
gbrindisi
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"

~~~
rflrob
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.

~~~
gbrindisi
I'm with you but still it's silly they didn't have a responsible disclosure
program until today in the first place.

~~~
simonbrown
They did.

------
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.

------
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.

------
skeletonjelly
"and we worked with him to fix it in a timely fashion"

Did this take place in private? I can't see any evidence of this from his
issue on the rails repo.

~~~
mojombo
Yes, this happened via our support system which all happens through private
emails.

------
dhconnelly
This is a great response to this clusterfuck. These guys have a responsibility
to react slowly and deliberately. I'm impressed they got the problem solved
and two public statements out on a Sunday. This is why I'm happy to be a
paying customer.

------
ashamedlion
Impressed by how Github handled this. It's easy to get red-faced and smack
down with a hammer, and it's hard to remain level-headed and come to the best
decision. This seems like it was, in fact, the best decision.

For those of you who didn't see, they were quick to update people and be on
the ball: [https://github.com/blog/1068-public-key-security-
vulnerabili...](https://github.com/blog/1068-public-key-security-
vulnerability-and-mitigation)

------
spullara
The thing I haven't heard a straight answer on is 1) how long has the bug
existed, 2) have they proved that it wasn't previously exploited.

~~~
luriel
1) Given the nature of the bug "for ever" seems like a good guess 2) I doubt
they can prove any such thing.

------
gnu8
(Ir)responsible disclosure always does more harm than good. Making these
issues public is the only reasonable thing to do.

~~~
mmj48
Disclosure does mean making things public...

------
ktizo
At least, after this, there should be a few people picking through github with
a pin to look for other vulnerabilities.

------
ig1
What the guy did was not only morally irresponsible but also criminal.

The security community has long has an accepted standard of responsible
disclosure, which involves informing the vulnerable party beforehand and
allowing them time to fix the problem before publicly disclosing it.

Publishing a vulnerability before giving those vulnerable a chance to fix it
is irresponsible, using it to compromise a system is criminal. He was getting
off light from getting his account suspended, GitHub could push for a criminal
prosecution resulting in deportation and serious jail-time for his actions.

It doesn't matter what he did after the compromise (whether it was benevolent
or not), the compromise of an account not held by him puts him clearly into
the "black-hat" category.

~~~
Karunamon
>the compromise of an account not held by him puts him clearly into the
"black-hat" category.

That's not what "black-hat" means.

~~~
ig1
Yes it does.

Gain unauthorized access to an account and using it falls under pretty much
any standard definition of "black-hat" and in practical terms breaks computer
security laws in pretty much all legal jurisdictions which have them.

~~~
Karunamon

        >Gain unauthorized access to an account and using it
    

Screw the motivations or the ends! The means are ALWAYS bad!

~~~
ig1
If you steal a loaf of bread to feed your family it's still a crime.

Regardless of whether or not you think what he did was justified it's still
illegal. And there's very few serious crimes for which "publicity stunt" will
generally be regarded as a good reason.

~~~
Karunamon
> it's still illegal.

Screw the law. Thinking that right/moral == legal is a very naive view of the
world.

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

~~~
gavingmiller
The straight up ban is a great short term solution, but in the long run being
easy to work with on security issues and not alienating your users is a better
road. As they stated, this user wasn't malicious so banning him only causes
grief and could turn him from an ally into an enemy.

There was a great post a couple of days back that in effect said: It's not a
matter of _if_ your security will be compromised but _when_. By being open to
your users disclosing this information you're helping to keep your product
secure. IMHO 37signals does a good job of this by linking and giving credit to
those that have discovered security flaws in their apps
(<http://37signals.com/security-response>).

