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.
Responsible Disclosure Policy
61–70 of 85 posts
Re: Responsible Disclosure Policy
#62Earlier quoted context omitted.
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?
In retrospect, it wasn't that helpful unless they also suspended new account creation, or at least kept an eye on it. But they didn't have that information at that time.
During a security breach, is suspending a malicious user who's currently attacking you really something you sit around and discuss beforehand? Or do you just do it?
Re: Responsible Disclosure Policy
#63Earlier 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.
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?
I'll take a guess and say it's because it's not possible to magically generate that code. If I wrote a code generator, there's no way that program could know which attributes should be accessible. The only way to get a scaffold to work out of the box is to require some user configuration or allow all attributes to be modifiable.
It's a case of ease-of-use trumping security.
Re: Responsible Disclosure Policy
#64Speaking 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"
More "an innocent kid was the only one not afraid to say that emperor is actually naked."
Please read this post written by meric, then give the counterarguments if you have them:
http://news.ycombinator.com/item?id=3665083
"I don't believe it is the stunt that costed github five to six figures. The loss of wealth was already there from day 1 when Github developers did not read Rails documentation and/or when Rails decided to make attributes publicly accessible by default. Today it is merely a "correction" where instead of Github's customer losing confidential company information without knowing it is now Github bearing the costs upfront, as it should be. In the "emperor has no clothes" story would you say it was the kid who pointed out the emperor had no clothes caused the emperor's embarrassment?"
You can also compare the whole context with the misfeature of PHP:
Re: Responsible Disclosure Policy
#65Earlier quoted context omitted.
I see this whole story as "Irresponsible kid accidentally teaches the whole town a lesson"
More "an innocent kid was the only one not afraid to say that emperor is actually naked." Please read this post written by meric, then give the counterarguments if you have them: http://news.ycombinator.com/item?id=3665083 "I don't believe it is the stunt that costed github five to six figures. The loss of wealth was already there from day 1 when Github developers did not read Rails documentation and/or when Rails de…
[deleted]
Re: Responsible Disclosure Policy
#66Earlier quoted context omitted.
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?
I'll take a guess and say it's because it's not possible to magically generate that code. If I wrote a code generator, there's no way that program could know which attributes should be accessible. The only way to get a scaffold to work out of the box is to require some user configuration or allow all attributes to be modifiable. It's a case of ease-of-use trumping security.
As homakov suggested, you could at least define *_id attributes as "protected" by default. Only being able to change attributes on your own records probably causes a lot less grieve.
Re: Responsible Disclosure Policy
#67Given 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…
I am with the others who say that you don't want to be too transparent over security handling.
One thing we do in LSMB is to "declassify" security issues when we do a full disclosure (usually two weeks after the patch is released).
The idea is that we fix, patch, announce the patch, wait, then issue full disclosure.
Re: Responsible Disclosure Policy
#68I 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.
I'm with you but still it's silly they didn't have a responsible disclosure program until today in the first place.
Re: Responsible Disclosure Policy
#69Earlier quoted context omitted.
I agree with you, but even if this was a reaction to public outcry the real reason to be disturbed is that top-notch Ruby devs like the GitHub guys didn't use attr_accessible. I can't wrap my mind around that. That you have to use attr_accessible is known throughout the Rails community since "ever". Only toy apps don't use it. It's like saving passwords in plaintext, only arguably even worse.
Or more specifically, since the public keys objects require an associated user, the old chestnut: @user.public_keys.build(...) .. where @user is retrieved in a role based manner (that is, you only get the right @user if you are authorized to get it.) Ultimately, this is less an issue of mass assignment specifically and more an overarching one of allowing a user to perform an action in the guise of another. But, of co…
No, that's not entirely correct.
You can do @user.public_keys.find(params[:id]).update_attributes(:user_id => 25)
Its the mass assignment protection on foreign keys that prevents you assigning one of your public keys to someone else, ensuring the chain is correct doesn't necessarily help with this scenario.
Re: Responsible Disclosure Policy
#70What 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.