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.
Responsible Disclosure Policy
21–30 of 85 posts
Re: Responsible Disclosure Policy
#22Given 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 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.
This is true. We actually don't use mass assignment that often. He happened to catch 2 our of 3 spots that still used it. Everywhere else is explicit about what to accept.
Re: Responsible Disclosure Policy
#23Honestly I have no idea why they didn't just ban him and say "don't hack us". It really should be that simple.
Re: Responsible Disclosure Policy
#24Earlier quoted context omitted.
If you're investigating a security situation, you don't have to say squat. Whether you were in the right or the wrong, explain what happened and apologize to those where were affected once the facts are understood , as they have done here. It takes time and energy to come up with responses such as this (not a lot, but every bit counts in an emergency), and those are resources that you should be using the solve the pr…
Not to mention that this happened on a Sunday.
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.
Re: Responsible Disclosure Policy
#25Given 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 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.
Re: Responsible Disclosure Policy
#26Earlier 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.
This is true. We actually don't use mass assignment that often. He happened to catch 2 our of 3 spots that still used it. Everywhere else is explicit about what to accept.
Ok, that is good to hear. Trust restored :) I was fearing you were using unsafe mass assignment everywhere...
Would you mind sharing any patters you use to DRY up explicit assignment?
Re: Responsible Disclosure Policy
#27Honestly, 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.
Re: Responsible Disclosure Policy
#28Earlier quoted context omitted.
This is true. We actually don't use mass assignment that often. He happened to catch 2 our of 3 spots that still used it. Everywhere else is explicit about what to accept.
Ok, that is good to hear. Trust restored :) I was fearing you were using unsafe mass assignment everywhere... Would you mind sharing any patters you use to DRY up explicit assignment?
We use this (posted by @dhh) https://gist.github.com/1975644 in some spots, or simply just Hash#slice. We have some other thoughts on making params access more explicit. The problem with explicit patterns is they can get left out if a developer forgets.
Re: Responsible Disclosure Policy
#29Honestly I have no idea why they didn't just ban him and say "don't hack us". It really should be that simple.
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).
Re: Responsible Disclosure Policy
#30Earlier quoted context omitted.
Not to mention that this happened on a Sunday.
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. This would take 3-5 hours, plus the amount of time it took us to get to the office and actually investigate the emergency. While we were investigating, we would likely shut down everything (including user accounts that were involved).
Weekends are time away from the office. I don't understand how you could expect the same amount of service on a weekend opposed to a week day. Do they deserve to be commended just because it was a weekend? Internally maybe, yes, externally maybe not. Fact remains that the weekend is when they are most likely to be short-staffed.