"Egor, stop hacking Github"
homakov.blogspot.com
homakov.blogspot.com
I know as hackers, we feel a duty to show people how serious these things are and that we get impatient and annoyed when ignored. And I also know that it's hard for us to reconcile the idea that when we show the owners rather than tell, it's suddenly considered a crime. But it is.
Let's try an analogy. Door locks on houses are ineffective. Think about it. Your house is covered with windows, which are made of glass. Glass is really easy to break. I mean really easy. If you found out your neighbor didn't have a house alarm, you might talk to them and tell them they should get one. If they didn't get one, would you then break into their house one night and walk into their bedroom to show them how dangerous it is?
OK, who knows, maybe you have a weird relationship with your neighbor. Furthermore, this is an imperfect analogy, because here, Rails and Github are both responsible for other people's property.
But now imagine it's a business across town and that you don't actually know the business owner. If you broke into their business to show them their building's security vulnerabilities, you bet your ass they would press charges and I don't think anyone would blame them. Even if you're doing it with the best intentions, it's still vandalism at best.
All of that being said, this is a very effective way of making your point and getting people to fix the problem. That doesn't make it right. But if you're willing to put yourself in harm's way and essentially become a martyr to get these security vulnerabilities fixed, more power to you.
[1] http://news.ycombinator.com/item?id=3643102
[2] http://www.inc.com/magazine/201203/burt-helm/a-silicon-valle...
But on the internet everyone's front door is accessible from even the most remote and hostile places in the world and you're pretty much on your own for securing it. Internet-facing systems also tend hold far more valuable things than your typical home.
For these reasons, I don't think the household lock analogy works very well.
---
I think you may be overestimating the effects of "the greater security picture" involving community, observant neighbors, other monitoring systems for the average community. For example, my first startup was RateMyStudentRental.com, and as I recall adding automated motion-activated sensors and lighting actually had a negative effect on break-in protection. As in, adding such a system actually increased your chances of having a break-in. According to the study, neighbors don't actually pay much attention to someone standing at a well-lit door (mileage varying based on the specific community obviously).
---
ORIGINAL EDIT: I won't comment on the technicality of the differences between the analogous situation and the actual situation at hand; the differences have nothing to do with the point being made. Don't get caught up in the analogy, because it's just an analogy.
In case it wasn't clear the first time around, the entire point of the analogy was that, breaking into and vandalizing someone's business just to show them that it can be done is generally a bad idea. Though I don't think anyone would argue it isn't effective.
Do you have a source for this? I've always been under the commonly held impression that this has a preventative effect, and it would be very interesting if the opposite really is true.
UPDATE: Hey, awesome, turns out we blogged about it back in the day: http://blog.ratemystudentrental.com/2008/03/05/a-safe-home-i...
Here is the original article: http://www.schneier.com/blog/archives/2007/09/light_and_crim...
Much so-called security lighting is designed with little thought for how eyes -- or criminals -- operate. Marcus Felson, a professor at the School of Criminal Justice at Rutgers University, has concluded that lighting is effective in preventing crime mainly if it enables people to notice criminal activity as it's taking place, and if it doesn't help criminals to see what they're doing. Bright, unshielded floodlights -- one of the most common types of outdoor security lighting in the country -- often fail on both counts, as do all-night lights installed on isolated structures or on parts of buildings that can't be observed by passersby (such as back doors). A burglar who is forced to use a flashlight, or whose movement triggers a security light controlled by an infrared motion sensor, is much more likely to be spotted than one whose presence is masked by the blinding glare of a poorly placed metal halide "wall pack." In the early seventies, the public-school system in San Antonio, Texas, began leaving many of its school buildings, parking lots, and other property dark at night and found that the no-lights policy not only reduced energy costs but also dramatically cut vandalism.
I remembered it incorrectly, as apparently motion-activated lighting helps, but on-all-night floodlighting makes the situation worse.
In short, sometimes darkness helps. Consider a tall glass office building. If all the lights are out, nothing stands out to a security guard more than a flashlight waving around in the darkness.
Of course, it's unfair to blame all those costs on the guy who had to go as far as actually escalating his privileges in order to unmask the Rails developers for being such knuckleheads.
For all we know, this bug has been abused for a long time to commit backdoors to other projects (perhaps those too big and active to notice).
In the white hat scenario, the first part does not exist and the white hat does not actually do anything harmful. The second part still exists and can cost tons of money, but this part is not the fault of the person who found the problem.
So while the costs _after_ a benign "intrusion" like was done to Github can be substantial - both in money and reputation, the costs _because_ of it are much less, since most of the costs weren't caused by it, it only exposed the pre-existing need of bear those costs. Like a doctor diagnosing somebody with serious illness - he's not at fault that the person now has to spend tons of money on drugs and medical procedures.
You have to assume every exploit will be abused. The most stupid thing you can do is attack the white hats, because the next hacker will shove your stupidity down your throat. On a lulz way or on a black hat way.
I would never let my data near a company which doesn't respect white hats, for security and moral reasons. I would remind you that we are on Hacker News, that doesn't exclude the popular meaning of the word.
I wouldn't throw a brick at a store window to make sure they have an alarm installed. Likewise, I wouldn't screw with someone else's production system to make sure they have X or Y security vulnerabilities patched. If you're worried about your own data, then try the exploits on your own account, or repository as the case may be. If it's a concern, get a hold of the company and let them know.
Easier said than done. It's hard enough to find the right people to talk to when people are so paranoid about connecting devs with customers, and if by chance you wind up talking to a PM first, the first thing he does is engage legal, which means instead of fixing the problem and protecting their customers and data, you may now be threatened with lawsuits, have the incident reported to the FBI or someone for investigation (on the assumption that you are in fact trying to extort them or something).
In this world, I'm not sure you can 'win' at this situation at present. Until there are protections for white hats that are broadly recognized, I'm going to side with people like Egor, who find a big damn problem and don't use it for ill.
Do you have something similar in the states?
But that's not the point. While we can be grateful for the CCC and the EFF for existing and doing the community a great service, we can also believe that their extraordinary contributions should be unnecessary.
Sometimes, it is actually necessary to pull down someone else's pants to expose a problem. I think the record here speaks for itself.
Maybe he did try to contact Github first, but I didn't see anything mentioning that in any of the linked posts.
Admittedly he did then do the online equivalent of pissing on the wall, so minus several million points for artistic endeavor.
I don't think I'm going to take this analogy any further though; things get dangerous when you base an argument entirely on analogy.
From the legal-dictionary [1]:
breaking and entering v., n. entering a residence or other enclosed property through the slightest amount of force (even pushing open a door), without authorization. If there is intent to commit a crime, this is burglary. If there is no such intent, the breaking and entering alone is probably at least illegal trespass, which is a misdemeanor crime.
[1] http://legal-dictionary.thefreedictionary.com/breaking+and+e...
I haven't looked at Egor's actions too closely, but he seems fairly close to a "white hat". He's been a bit immature, and so has Github, but there's been no real lasting damage.
Anyone who's written a web app knows that mistakes can happen, and they take time to fix. I'm sure Github will handle the PR crisis with an informative and unbiased mea culpa (even if they secretly think Egor was a bit brash). People will keep using them, because their interface rocks.
This will stay on the front page for about 24 hours, then there will be a few link bait articles that also cash in on it, but that's about it.
This rails behavior is actually even more powerful than the old PHP one for hackers because with this you get directly into the model and then the DB when everything is still left as generated, not just the temporary variables. It's actually pretty surprising how much resistance there is to fixing the issue.
It could be that the proposed whitelisting isn't the only solution. It does require annoying configuration. With PHP, nowadays, most people just access a particular array when they want their request variables. Similarly, maybe Rails could have a request model object and a DB model object with simple methods for copying state between the two. Maybe combine it into some sort of validation logic with user friendly error messages being specified. I guess it is still more work that default overwriting of the DB with request variables, though.
But seriously, PHP still has lots of problems to fix.
Like what?
Also, reddit? Really?
Really? 5.4 has fixed the retarded associativity of the ternary and all error reporting?
Ruby and Python are much more consistent in that regard.
http://www.yiiframework.com/wiki/161/understanding-safe-vali...
If a field doesn't have any validation rules set it will be thrown out when you save the model. This way you won't mass-assign to a column that was never meant to be mutable. Its a little more work to get up and running, but I think its a good tradeoff.
(You do have the option of turning this off, but you'd have to do it intentionally).
Obviously this situation is a bit more complicated, as a ticket was opened up, and a lot of community discussion occurred. In general, emails to the security list are taken extremely seriously.
What should he have reported to rails security team? Shouldn't he have been contacting GH security team instead?
Edit: Rails guides discusses the root cause and counter measures against these type of vulnerabilities http://guides.rubyonrails.org/security.html#mass-assignment
What Rails have done is to have a particular default (whose correctness can be debated) and document how it can be exploited and how to safeguard from it.
http://guides.rubyonrails.org/getting_started.html#say-hello...
You'd be forgiven for thinking there was no vulnerability, given the lack of warning over that sort of code, and the fact that Rails does a lot of 'magic' behind the scenes (especially since you're using their own helper classes to handle form input and such like).
No, this isn't a "Rails vulnerability" in the traditional sense, but the level of immaturity and groupthink in the response to these issues being reported is staggering and somewhat shameful.
I think that perhaps the Rails team should have someone reviewing that issues were properly handled.
(1) it has seemingly embarrassed some rails committers into taking this seriously, whereas they dismissed the issue before;
(2) I bet there were at least 20 devs who saw this on HN, said fuck my life, and hopped on their vpn to check if their site is vulnerable.
No drama disclosures didn't accomplish either of these things. Hopefully github won't take it too personally, and Egor was actually (as he seemed!) careful not to break anything.
This is the type of ridiculous stuff we used to expect from PHP years ago.
It is not a bug. It's an acknowledged part of the framework (http://guides.rubyonrails.org/security.html#mass-assignment), although one that could get a developer into trouble without knowing to protect attributes where necessary.
If he'd known that there was something the GH team missed, he should have just brought the issue to them directly. If I realize my neighbor's house is in danger of collapsing because the contractor used the wrong type of wood, I don't bring the issue up with a lumber yard and then knock over my neighbor's house to prove a point when they ignore me.
I agree that it's a problem that many developers aren't aware that they need to protect against mass assignment, but it seems like this dude is totally misunderstanding the entire ecosystem here, and now people are calling him a "hero" because he took advantage of something that everyone already knows.
Big whoop.
Yes, you do. Because the lumber yard sold your neighbor the wrong wood.
If you're going to make a framework for a language, do so in a manner that discourages stupidity.
PHP learned this the hard way quite a few years back. You never make things easier for the end-user at the expense of security. It's time for Rails to learn the same lesson.
Would be kind of scary if he had injected some nastiness into the rvm repo master branch, for instance, because I know some people do ride on the master version (`rvm get head`). Or, some gems that are built from Gemfile's pointing at the git repo on GitHub.
Luckily, git itself is quite resilient to attacks on the repo integrity so I don't think there could be much long-term harm done (no rewriting repo history would go unnoticed, for example).
Others just don't realize it yet because they're going through the stages of grief (Denial, Anger, Bargaining, Depression, Acceptance). https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model
If no one else says it, I will:
Thank You!
"Then, I could make a post pretending i am DHH. That was funny too."
"GH sorry, I was bored."
Im sure everyone has different definitions, for me its just someone that I wouldn't wanna hangout with on a personal level, that's all.
Give the guy a break.
On balance I think he's just a well-meaning kid who's achieved notoriety the wrong way, but his deepest intentions are good.
Rather like Robert Tappan Morris, come to think of it!
While this is a legit bug on github, and Egor deserves credit for finding it, he also deserves a scolding for the classic noob mistake of not reporting it to the right place.
http://homakov.blogspot.com/2011/07/octocat-tattoo.html
That tattoo is legit.
Sounds like this was already a known problem that has led developers to shoot themselves in the foot.
I don't know how else he could have done this. He was being ingored!
What _really_ happened is that he was told, "no, we think that this is the application developer's responsibility." He became frustrated that the response wasn't what he had anticipated, so instead of acting like a mature software developer he started acting like a petulant child.
The point is, this Github exploit could still exist even if some protections were set by the framework. Developers should take their app's security into their own hands (and I'm sure Github does) by employing a solution similar to attr_accessible.
Assuming no economic impact to github you mean. If paying users leave because they feel github is no longer safe for private repos because of this, that is harm.
I imagine a bank would be far more grouchy if someone exploited a vulnerability and deposited one cent into someone's account "just to show there was a vulnerability" then publicized it, without talking to them about it first. <sarcasm>No harm done right?</sarcasm>
Now, I am not saying that it is bad that this github vulnerability was found and fixed. I am very glad! But I think it could have been far more responsibly done.
But if github users quit because a hacker shows them github is insecure, that's harm github did to itself. Don't blame the messenger.
Then he proves his point, without hurting anyone. In my book, that deserves an A.
[1] http://guides.rubyonrails.org/security.html#mass-assignment