11 ms·

GitHub and Rails: You have let us all down.

590 points by chrisacky 15y ago

tmcdonald 15y ago
I'm not sure all the things you list as being possible are true. - Every GitHub Repository could be access by anyone as if they had full administrator privileges. - This means that anyone could commit to master. - This means that anyone could reopen and close issues in issue tracker. - Even the *entire* history of a project could be wiped out. Gone forever. As I understand it from his explanation[1] he added his public key to the Rails user, which has permissions to push/pull to the repository. This doesn't mean he had web administrative access, just Git access, since you cannot log in to the web service using your private key. I hope that's the case, at least. [1]: http://homakov.blogspot.com/2012/03/how-to.html http://homakov.blogspot.com/2012/03/how-to.html
- lrm242 15y ago
  The way he was able to add his key was via a web-based exploit, which effectively gave him administrative web access. So yes, the list is correct.
  - tmcdonald 15y ago
    I thought that he added his public key to the Rails user through his own account settings, which wouldn't give him access to the Rails web admin.
    - chrisrhoden 15y ago
      This is correct. People who don't understand what a mass-assignment bug is are running with this story. It's like when we witness a DDoS and have to tollerate people who think it means that the targeted party was infiltrated. This bug allowed one to add their public key to another user's account, and make changes to comments and issues.
      - deleted 15y ago
        [deleted]
      - anthonyb 15y ago
        What are the odds that there's a similar bug which allows changes to user accounts? If that's the case, then altering the password or email address is trivial.
- bcrescimanno 15y ago
  FWIW, that last bullet, aside from being the most egregious example of hyperbole in TFA, shows a complete lack of understanding of how git works.
  - refulgentis 15y ago
    Nothing in the article would lead one to believe he didn't understand the distributed nature of git repositories, but a lot in the article would lead one to believe he was specifically referring to the data loss issues on GitHub if someone wiped out a project.
    - icebraining 15y ago
      If the project was deleted from Github, you'd just have to create a new one push a local clone to it. That's hardly what that point is saying.
ktizo 15y ago
I'm starting to like homakov more after reading this article.
ericflo 15y ago
I fail to see what GitHub did wrong here. They were attacked, they suspended the account doing the hacking, and they fixed the problem. Then, they blogged about it, explaining in detail what happened. Apparently they weren't quite reverent enough for the person who wrote this article.
- deleted 15y ago
  [deleted]
- vidarh 15y ago
  I lost a tremendous amount of respect for Github when I heard they'd suspended his account. I have more of an issue with the Rails team for not accepting that this "feature" is a massive bug that they should've changed ages ago, though.
  - ericflo 15y ago
    Why? I would expect any company to suspend the account of someone hacking them.
    - silentOpen 15y ago
      When you've tried to inform the vendor and have been rebuffed, a demonstration of the vulnerability helps convey the gravity of the issue.
    - vidarh 15y ago
      He did it under his own name, in a way dad not damage anything, using a problem that has been well known for ages, after attempting to draw attention to the issue several times and being ignored. It is pretty obvious that he did not have any malicious intent, nor intended to do damage (if he wanted to, he could've done massive damage from an anonymous account in ways that wouldn't draw attention to it). The only thing suspending his account accomplished is to punish someone who has helped draw attention to a very serious problem. It just comes across as an incredibly childish and petty response given the circumstances.
elithrar 15y ago
> When the large portion of the technical world all depends on a single service, and that service is vulnerable to a variety of attacks, that makes anyone who consumes these services also vulnerable. I don't mean to diminish the severity of this exploit, and the impact it has/could have had if left unchecked. BUT, isn't one of the biggest perks of Git the fact that it's a distributed SCM? It's not a service where you must trust all of your data with the one provider, who might go belly up at any point and take it with them. Yes, GitHub provides some fantastic social features and helps with community involvement through these features, but if you are dependant on a "single service" and you're using a DSCM/DVCS, you should probably look at a few alternatives to reduce that dependancy.
- ricardobeat 15y ago
  People use services like GitHub because they provide security, reliability, uptime, protection against hw failure, centralized issues and patches, and so on. If we have to worry about each of these on our pwn, what's the point?
  - elithrar 15y ago
    > If we have to worry about each of these on our pwn, what's the point? You should always have to worry about these things, regardless of who's hosting things. It just so happens that Github, to date, has been checking the boxes in these areas and has established a reputation for doing so. But, if GitHub losing your repo/having it trashed beyond repair will kill your project (or severely hamper it), the cost of setting up a second Git server and a couple of hooks to mirror your push is very low, in both dollars and man-hours.
    - maratd 15y ago
      That's not how git works. I have the entire repo locally. If I didn't, I wouldn't be able to commit anything. So if Github goes poof, I'd be pissed, but I wouldn't lose a single line of code. I would obviously lose things like issues/wiki. Actually, it would be pretty cool if Github turned issues/wiki into some sort of git repo of markdown files and allow me to pull them and commit to them. Something for them to think about =)
endlessvoid94 15y ago
> Beyond any shadow of a doubt, a shit storm of epic proportions has just gone down. Breathe.
- ktizo 15y ago
  ...but don't relax, it might be messy
telent 15y ago
AFFECT, grrr. Not effect. To effect every coder would be to bring them all into existence, which is clearly not what happened here.
dkrich 15y ago
Give me an F'in break. I understand security is not something to take lightly, but no system is infallible. There was an oversight, plain and simple. It is debatable whether the Github/Rails Core Team was too lax, but I for one am tired of hearing developers whine and make a witch trial out of groups of developers that have moved the development community forward several huge steps just to make themselves sound smart or feel fulfilled. If you're such a hero, why didn't you discover this loophole? Please stop writing provocative statements and behaving as if the sky is falling on top of your head and the very fiber of our being is at stake. An open source language and a website written in that language were shown to have a flaw. Which has since been fixed. I hate developers who like to sound smart at the expense of somebody else. Get over yourself. I also don't see how you can blast Github for its oversight of this issue but then defend the "hundreds of thousands" of sites that use Rails. Aren't they as culpable? Oh, I suppose Github is held to a higher standard than the rest of the dependent apps. If this is Github's fault, then it is also every other developer's fault who doesn't by default disable mass-assignment of attributes.
- unseen 15y ago
  It's not a flaw, because the flaw in this case was a feature! That's what we call "insecure by design". Its PHPs register_globals all over again.
- refulgentis 15y ago
  You're conflating two issues here. He's arguing that the Rails team was ignoring an important issue by noting it was an easy end-user fix, and GitHub overreacted by suspending him after he tried several times to bring it to their attention, and then grossly mislead their user base as to the extent of the issue (which sounds like a really fundamental security issue that any professional Rails developer should know how to avoid) and how they discovered it (i.e. they didn't discover it, they had to be shown it). You're responding as if GitHub was simply being attacked for not fixing the issue.
  - dkrich 15y ago
    Fair enough. Ignoring the issue and not fixing it after it was brought to their attention to me is where they screwed up. As for the account suspension, I'm not sure I agree that the account should not have been suspended. Github is a code repository first, and I don't think they have an obligation to keep people around who are exposing security flaws by notifying the entire community. As the author of the post points out, hundreds of thousands of apps rely on Github, so to an extent it is their responsibility to block people who may jeopardize their users. Let's say that they left his account active, and then two months from now he exposed a larger security flaw by greatly damaging a users' app or business. I'll bet there would be more posts like this one blasting Github for not suspending his account. Personally, I think they should offer him a job.
collypops 15y ago
> Beyond any shadow of a doubt, a shit storm of epic proportions has just gone down... > ...this episode has been handled is a face-palm fail of epic proportions. I'm all for, like, the evolution of language, but can we please all, like, agree that 'fail' isn't, like, a noun, and 'epic' is, like, totally overused.
- marekmroz 15y ago
  And don't get me started on "should of", used twice in this article...
Kiro 15y ago
"If you are one of those strange coders that don't use GitHub". Never used and never will. What's strange with that?
- forrestthewoods 15y ago
  That comment jumped out at me as well. I use Perforce at work and run my own at home. Both with local and offsite redundancy. I guess that makes me strange.
- zalew 15y ago
  "If you are one of those strange coders that don't use GitHub and think you are in the clear because you use SVN/Mercurial" I can't believe he actually put SVN and Mercurial on the same side, or that he implies that not using GitHub must mean that you don't use Git at all. This sentence is wrong on so many levels. Sigh.. I'm strange, for my actual work I use Mercurial hosted on BitBucket.
  - p4bl0 15y ago
    I stopped reading when I saw that the author can't distinguish GitHub and Git usage…
- bobbles 15y ago
  It must have been updated recently as there are now <sarcasm> tags around the 'strange'
- chops 15y ago
  Sounds like sarcasm to me.
epistasis 15y ago
I have lost all trust in GitHub, and not because of the vulnerability, but because of their response. With their suspension of hamakov's account and deceptive blog post about the extent of the hole, GitHub has guaranteed that they won't be the first to know about the next vulnerability (and there's always another). I've downgraded my paid account to a free account, and won't keep any non-public data on GitHub in the future. I had a similar response with my (non-paid) DropBox account. I guess I didn't rationally evaluate cloud resources, and have trusted far too many people.
- codesuela 15y ago
  ^ this, I just moved my prive repo to bitbucket hoping that Atlassian would have handled this issue better. At least they seem to have more experience looking at their long history in software. I will also look into setting up my own git(orious) server.
  - DeusExMachina 15y ago
    I personally know some people that work for Atlassian and they are awesome. Moreover, they really do care for their customers. I have no experience using Bitbucket, but given the people I know I would definitely trust them.
- phzbOx 15y ago
  I have to agree that suspending the account was dumb as if he wanted to be malicious, he'd have created dummy accounts and would have committed malicious code to popular projects. But then, going so far to say losing all trust in github.. there was a bug, it's fixed and they suspended the "attacker". I wonder what will happen in the following days with script kiddies trying to "hack" all rails website. In fact, isn't the overloading of parameters something as old as the earth that security experts would check first as a vulnerability?
- chrisacky 15y ago
  This is a perfect summary and exactly the sentiments that I couldn't express in the article. I've quoted you with attribution if you are okay with that?
deleted 15y ago
[deleted]
mkramlich 15y ago
I'm not too worried about the ability of an attack to push a commit, or cause a commit/object deletion in a repo's history, on GH, because most smart folks (if not everybody, by default) will have multiple copies of a repo across multiple machines, with backups, so anything can be undone or restored. (And trust me, I have the imagination to understand how an unauthorized commit/push could lead to a situation enabling remote execution on client machines who've pulled down tainted commits. Think build scripts that have "install rootkit/malware/keylogger" commands added to them in the mal commits.) What would be more bad is if this vulnerability allowed an attacker to get unauthorized read access or pull/clone access to a private GH repo. Can anyone clarify for me whether this was possible?
jtchang 15y ago
The one "good" thing that comes out of this public exploit is that github was the target. Github is obscure enough to non-developers but quite well known in the development circle. This means if you are using github you probably have a damn good idea what the vulnerability is. I'm not a rails developer (mostly python/django) but I get it immediately. This is mostly an issue with the framework helping me shoot myself in the foot. Sure it's in the documentation. But realistically a good framework gives me sensible defaults so I don't have to refer to the documentation. I trust the framework does the "right thing".
deleted 15y ago
[deleted]
- deleted 15y ago
  [deleted]
alinajaf 15y ago
Though I will say that mass assignment is about as rookie a rails mistake as you can make, I won't be leaving github. They've delivered so much value over the past four years for me that I can forgive them this and I'd still have (a little) goodwill towards them left over.
colinmarc 15y ago
+1 for the usage of "github-gate."
spqr 15y ago
That's a shame. Sincerely, a .NET developer.
latetothepatty 15y ago
I used GitHub and I'm not moving my stuff off. If an app gets hacked, then not long after, that app will likely be the most secure place. GitHub at least keeps it up most of the time. Who you really should be mad at are the Rails maintainers and the RoR community. I switched from Java to Ruby a few years back, and since day one, everyone using Rails has been slack on security. The reason is that they make things too easy to leave wide open. Don't believe me? Read the Rails official documentation for starting off. It is all about ease of use, not security. If you are new, you have no idea what you've really left open even when you just generate a scaffold as they show you to do. The main thing that Rails security has going for it is that the adoption of Rails is still relatively low, and because a newbie isn't likely to scale their app well, odds are you won't have an extremely popular, extremely performant Rails app that is just asking to be hacked that easily.
tlianza 15y ago
I'm not sure if everyone noticed the last comment on this article: http://screencast.com/t/Nobted7zv5z http://screencast.com/t/Nobted7zv5z Posted "almost 8 years ago" ie. posterous would appear to have the same vulnerability.
- mofey 15y ago
  Isn't that Twitter?
- deleted 15y ago
  [deleted]
- zedshaw 15y ago
  Ha! Alright he probably should quit doing that before he gets KimDotcom'd.
  - getsat 15y ago
    Russia has no extradition treaty with the US. He's fine.
knodi 15y ago
This is the first thing in securing your rails app a developer learns, how to properly handle mass-assignment. I don't blame rails, I blame Github.
- javascriptlol 15y ago
  A system that is designed to rely on human diligence is inherently flawed. It's a mercy that drills and other dangerous tools aren't designed in the same way that a lot of software is.
  - unimpressive 15y ago
    Exactly. This is like saying that it was fine for older versions of windows to broadcast the users directory tree over an open file server because they should know better than to leave the server up. (This happened right? Correct me if it didn't.) It's like no, you should have to turn the server on in the first place. The fact that it took some Russian kid in his basement breaking into the github rails master for this self evident truth to be realized by the core rails team is totally outrageous.
eli_gottlieb 15y ago
Oh, they've let you all down? Then stop using other people's web applications and just run your own git/hg server. With blackjack, and hookers. You are vulnerable to someone else's fuck-ups as long as you insist on giving up control over your data and code in exchange for the convenience of someone else doing the "hard work" of development and administration for you. Hell, restore the network to being peer-to-peer rather than hierarchical, and hosting your own whatever will no longer be such a damn problem.
n8agrin 15y ago
There is so much bombastic talk in this post. This has to be a troll.
raganwald 15y ago
As Zed Shaw pointed out, someone appearing to be Homakov has posted a comment dating back eight years. Is Posterous vulnerable as well? If so, that may not be Homakov, of course, but his twitter comments are consistent with him posting it. https://twitter.com/zedshaw/status/176497720817762304 https://twitter.com/zedshaw/status/176497720817762304
- jsnell 15y ago
  Yes, one of Egor's comments in the github bugtracker had a small (but presumably not exhaustive) list of other vulnerable sites. It included Posterous.
trotsky 15y ago
Jesus, HN goes from zero to lynch mob faster than reddit these days. Guy drops a zero day on a major service provider, guy gets his account suspended (temporarily, it turns out). In what possible world is disabling an account that has recently exploited your live product in a very visible way not ok? Remember, you don't have a chance to call a meeting with the C level guys and your community manager - you're one or two guys responding on a weekend. The rest of the "oh my god the sky is falling" drivel about how terrible a bug it could have been and how they should never have had such a vulnerable bug in the first place is even worse. Security bugs are fuckups by nature - nobody sat and said well shit I was going to code this wrong but since it might allow a lot of access I won't. In terms of OH SHIT bugs this is actually rather small - I'm sure github's live infrastructure has been open to lower level remote execution vulnerabilities over the years - newsflash: we all have been. Getting user or superuser or db admin is going to almost certainly be a lot worse than an application authentication level vulnerability. You say none of that matters because it's such an obvious bug and people have known not to do that kind of thing for years? Say hello to our old friends "buffer overflow" & "use after free" - still grabbing msft aapl & goog after all these years. TL;DR - stop acting like children.
- reidmain 15y ago
  Correct me if I'm wrong but this wasn't a "zero day". This issue was brought up four days ago https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228
  - trotsky 15y ago
    I thought there were two different issues, though not being a rails jockey I could easily be mistaken. Even if it was disclosed four days before it was exploited I stand by my take if not my terminology.
    - masklinn 15y ago
      > I thought there were two different issues Nope, this bug is exactly what he used for his demonstration (and there are warnings about attr_accessible going back 3 or 4 years, so it's not a "0-day" by most accounts, more of a "3-years"" vuln)
ggwicz 15y ago
Shut the fuck up. How many companies get hacked regularly like this but keep it under the rug? You think FaceBook's never been exploited? TurboTax? Mint? Stripe? PayPal? Shopify? Tumblr? Pick your app that "so so so so many businesses" use regularly, and I guarantee something like this has happened with all of them. But were they open about it? GitHub's been open the whole time. Your post is like saying "All criminals are stupid". This is ridiculous, as the only sample you know of and can work with are the criminals who have been caught. You don't know how many other criminals are out there getting away with their crimes, because...they haven't been caught yet. Who knows how many other companies have had hacks like this in the past two months alone, for example? I don't, and neither do you. But GitHub, as an open, honest company that so so so many of use regularly (which means we know right away when there's a problem, especially with a hugely popular repo like Rails/rails) has been in the spotlight since the second this happened. GitHub, in my opinion, has acted really cool about this. They addressed the issue, explained what the issue is, patched the hole, and even reinstated the hacker's account. DHH addressed the issue in twitter, other people in the community have admitted they fucked up, and now we as a community can work on fixing this. That doesn't sound like "Letting us all down". Someone who expects everything to work perfectly all the time and have no vulnerabilities is someone will be let down by anything, a pessimist, and stupid. And certainly not worthy of the front page of Hacker News.
aneth 15y ago
The response to this makes me feel that HackerNews is now populated by a bunch of pretenders. This "bug" has been in Rails since Day 1, and any remotely experienced Rails developer is aware of this functionality. You can argue for a different default, but it's not a bug. Github did have a bug and noone knowledgeable about Rails appears to have made even a cursory inspection of the security of their controllers - which is where attribute protection actually belongs, since different controllers and different users change different attributes. Protected attributes is a blunt tool for simple situations, which is why it's not enabled by default. Github had a pretty terrible bug, discovered, and fixed it. They may not have handled it perfectly, but the certainly don't deserve this sort of mon hatred - any competitor you go to is likely to have security flaws as well, perhaps more severe and subtle. @homako didn't just expose the bug in github, he exploited it to make an unauthorized commit to Rails master. His account most certainly should have been at least temporarily suspended as GitHub had no idea what else he might do to prove his point. So basically, most of the comments here are glaringly wrong or ignorant bandwagoning, and it makes me wonder about the accuracy of information here about topics I'm less familiar with. A sad day when you realize all this intelligent discussion you thought you'd been reading about new topics was probably just grandstanding by eloquent fools.
- dasil003 15y ago
  Normally I respond negatively to this type of post, but you've captured my feelings perfectly. The facts here are nothing that should be blown so far out of proportion. I can't help but detect a hint of schadenfreude at the idea that Rails core or Github are not infallible.
- gurkendoktor 15y ago
  > Github did have a bug and noone knowledgeable about Rails appears to have made even a cursory inspection of the security of their controllers > Github had a pretty terrible bug > but the certainly don't deserve this sort of mon hatred For all the free fun you can have on github, they are in the business of selling private repositories. What could possibly have been worse than someone finding a bunch of bugs in a matter of days just to prove a point about Rails?
meow 15y ago
For me the sad part is that there is an almost even split between people arguing the right way to bring this issue to every ones notice. I think this is the perfect way to show how serious the issue is and to get more sites to adopt the fix. Exploits like this are worth a lot on black market. They are worth even more if you provide a precious and vulnerable target to go along (github).
edu 15y ago
Posterous is down?
tlowrimore 15y ago
I'm sorry, but this feels to me like an over-dramatized heap of bullshit. First, the statement, "Rails. You clearly messed up." is self righteous bullshit at its finest. Rails didn't mess up; the programmer(s) at Github messed up. No conscientious developer lets the end user mass-assign variables carte blanche. But with that said, _every_ developer messes up every now and then despite their best efforts; some times they mess up in a big way. Secondly, if a user discovered a vulnerability in something I wrote, and they handled it like homakov did, I'd ban the shit of them until I knew for sure that they weren't a threat. Finally, Github handled this exactly the way many companies would handle it: it's called damage control. These guys are really good at what they do, they provide a great service and they offer-up a lot of their tools to the FOSS community.

590 points by chrisacky 15y ago

I'm not sure all the things you list as being possible are true. - Every GitHub Repository could be access by anyone as if they had full administrator privileges. - This means that anyone could commit to master. - This means that anyone could reopen and close issues in issue tracker. - Even the *entire* history of a project could be wiped out. Gone forever. As I understand it from his explanation[1] he added his public key to the Rails user, which has permissions to push/pull to the repository. This doesn't mean he had web administrative access, just Git access, since you cannot log in to the web service using your private key. I hope that's the case, at least. [1]: http://homakov.blogspot.com/2012/03/how-to.html http://homakov.blogspot.com/2012/03/how-to.html

lrm242 15y ago
The way he was able to add his key was via a web-based exploit, which effectively gave him administrative web access. So yes, the list is correct.
- tmcdonald 15y ago
  I thought that he added his public key to the Rails user through his own account settings, which wouldn't give him access to the Rails web admin.
  - chrisrhoden 15y ago
    This is correct. People who don't understand what a mass-assignment bug is are running with this story. It's like when we witness a DDoS and have to tollerate people who think it means that the targeted party was infiltrated. This bug allowed one to add their public key to another user's account, and make changes to comments and issues.
    - deleted 15y ago
      [deleted]
    - anthonyb 15y ago
      What are the odds that there's a similar bug which allows changes to user accounts? If that's the case, then altering the password or email address is trivial.
bcrescimanno 15y ago
FWIW, that last bullet, aside from being the most egregious example of hyperbole in TFA, shows a complete lack of understanding of how git works.
- refulgentis 15y ago
  Nothing in the article would lead one to believe he didn't understand the distributed nature of git repositories, but a lot in the article would lead one to believe he was specifically referring to the data loss issues on GitHub if someone wiped out a project.
  - icebraining 15y ago
    If the project was deleted from Github, you'd just have to create a new one push a local clone to it. That's hardly what that point is saying.

ktizo 15y ago

I'm starting to like homakov more after reading this article.

ericflo 15y ago

I fail to see what GitHub did wrong here. They were attacked, they suspended the account doing the hacking, and they fixed the problem. Then, they blogged about it, explaining in detail what happened. Apparently they weren't quite reverent enough for the person who wrote this article.

deleted 15y ago
[deleted]
vidarh 15y ago
I lost a tremendous amount of respect for Github when I heard they'd suspended his account. I have more of an issue with the Rails team for not accepting that this "feature" is a massive bug that they should've changed ages ago, though.
- ericflo 15y ago
  Why? I would expect any company to suspend the account of someone hacking them.
  - silentOpen 15y ago
    When you've tried to inform the vendor and have been rebuffed, a demonstration of the vulnerability helps convey the gravity of the issue.
  - vidarh 15y ago
    He did it under his own name, in a way dad not damage anything, using a problem that has been well known for ages, after attempting to draw attention to the issue several times and being ignored. It is pretty obvious that he did not have any malicious intent, nor intended to do damage (if he wanted to, he could've done massive damage from an anonymous account in ways that wouldn't draw attention to it). The only thing suspending his account accomplished is to punish someone who has helped draw attention to a very serious problem. It just comes across as an incredibly childish and petty response given the circumstances.

elithrar 15y ago

> When the large portion of the technical world all depends on a single service, and that service is vulnerable to a variety of attacks, that makes anyone who consumes these services also vulnerable. I don't mean to diminish the severity of this exploit, and the impact it has/could have had if left unchecked. BUT, isn't one of the biggest perks of Git the fact that it's a distributed SCM? It's not a service where you must trust all of your data with the one provider, who might go belly up at any point and take it with them. Yes, GitHub provides some fantastic social features and helps with community involvement through these features, but if you are dependant on a "single service" and you're using a DSCM/DVCS, you should probably look at a few alternatives to reduce that dependancy.

ricardobeat 15y ago
People use services like GitHub because they provide security, reliability, uptime, protection against hw failure, centralized issues and patches, and so on. If we have to worry about each of these on our pwn, what's the point?
- elithrar 15y ago
  > If we have to worry about each of these on our pwn, what's the point? You should always have to worry about these things, regardless of who's hosting things. It just so happens that Github, to date, has been checking the boxes in these areas and has established a reputation for doing so. But, if GitHub losing your repo/having it trashed beyond repair will kill your project (or severely hamper it), the cost of setting up a second Git server and a couple of hooks to mirror your push is very low, in both dollars and man-hours.
  - maratd 15y ago
    That's not how git works. I have the entire repo locally. If I didn't, I wouldn't be able to commit anything. So if Github goes poof, I'd be pissed, but I wouldn't lose a single line of code. I would obviously lose things like issues/wiki. Actually, it would be pretty cool if Github turned issues/wiki into some sort of git repo of markdown files and allow me to pull them and commit to them. Something for them to think about =)

endlessvoid94 15y ago

> Beyond any shadow of a doubt, a shit storm of epic proportions has just gone down. Breathe.

ktizo 15y ago
...but don't relax, it might be messy

telent 15y ago

AFFECT, grrr. Not effect. To effect every coder would be to bring them all into existence, which is clearly not what happened here.

dkrich 15y ago

Give me an F'in break. I understand security is not something to take lightly, but no system is infallible. There was an oversight, plain and simple. It is debatable whether the Github/Rails Core Team was too lax, but I for one am tired of hearing developers whine and make a witch trial out of groups of developers that have moved the development community forward several huge steps just to make themselves sound smart or feel fulfilled. If you're such a hero, why didn't you discover this loophole? Please stop writing provocative statements and behaving as if the sky is falling on top of your head and the very fiber of our being is at stake. An open source language and a website written in that language were shown to have a flaw. Which has since been fixed. I hate developers who like to sound smart at the expense of somebody else. Get over yourself. I also don't see how you can blast Github for its oversight of this issue but then defend the "hundreds of thousands" of sites that use Rails. Aren't they as culpable? Oh, I suppose Github is held to a higher standard than the rest of the dependent apps. If this is Github's fault, then it is also every other developer's fault who doesn't by default disable mass-assignment of attributes.

unseen 15y ago
It's not a flaw, because the flaw in this case was a feature! That's what we call "insecure by design". Its PHPs register_globals all over again.
refulgentis 15y ago
You're conflating two issues here. He's arguing that the Rails team was ignoring an important issue by noting it was an easy end-user fix, and GitHub overreacted by suspending him after he tried several times to bring it to their attention, and then grossly mislead their user base as to the extent of the issue (which sounds like a really fundamental security issue that any professional Rails developer should know how to avoid) and how they discovered it (i.e. they didn't discover it, they had to be shown it). You're responding as if GitHub was simply being attacked for not fixing the issue.
- dkrich 15y ago
  Fair enough. Ignoring the issue and not fixing it after it was brought to their attention to me is where they screwed up. As for the account suspension, I'm not sure I agree that the account should not have been suspended. Github is a code repository first, and I don't think they have an obligation to keep people around who are exposing security flaws by notifying the entire community. As the author of the post points out, hundreds of thousands of apps rely on Github, so to an extent it is their responsibility to block people who may jeopardize their users. Let's say that they left his account active, and then two months from now he exposed a larger security flaw by greatly damaging a users' app or business. I'll bet there would be more posts like this one blasting Github for not suspending his account. Personally, I think they should offer him a job.

collypops 15y ago

> Beyond any shadow of a doubt, a shit storm of epic proportions has just gone down... > ...this episode has been handled is a face-palm fail of epic proportions. I'm all for, like, the evolution of language, but can we please all, like, agree that 'fail' isn't, like, a noun, and 'epic' is, like, totally overused.

marekmroz 15y ago
And don't get me started on "should of", used twice in this article...

Kiro 15y ago

"If you are one of those strange coders that don't use GitHub". Never used and never will. What's strange with that?

forrestthewoods 15y ago
That comment jumped out at me as well. I use Perforce at work and run my own at home. Both with local and offsite redundancy. I guess that makes me strange.
zalew 15y ago
"If you are one of those strange coders that don't use GitHub and think you are in the clear because you use SVN/Mercurial" I can't believe he actually put SVN and Mercurial on the same side, or that he implies that not using GitHub must mean that you don't use Git at all. This sentence is wrong on so many levels. Sigh.. I'm strange, for my actual work I use Mercurial hosted on BitBucket.
- p4bl0 15y ago
  I stopped reading when I saw that the author can't distinguish GitHub and Git usage…
bobbles 15y ago
It must have been updated recently as there are now <sarcasm> tags around the 'strange'
chops 15y ago
Sounds like sarcasm to me.

epistasis 15y ago

I have lost all trust in GitHub, and not because of the vulnerability, but because of their response. With their suspension of hamakov's account and deceptive blog post about the extent of the hole, GitHub has guaranteed that they won't be the first to know about the next vulnerability (and there's always another). I've downgraded my paid account to a free account, and won't keep any non-public data on GitHub in the future. I had a similar response with my (non-paid) DropBox account. I guess I didn't rationally evaluate cloud resources, and have trusted far too many people.

codesuela 15y ago
^ this, I just moved my prive repo to bitbucket hoping that Atlassian would have handled this issue better. At least they seem to have more experience looking at their long history in software. I will also look into setting up my own git(orious) server.
- DeusExMachina 15y ago
  I personally know some people that work for Atlassian and they are awesome. Moreover, they really do care for their customers. I have no experience using Bitbucket, but given the people I know I would definitely trust them.
phzbOx 15y ago
I have to agree that suspending the account was dumb as if he wanted to be malicious, he'd have created dummy accounts and would have committed malicious code to popular projects. But then, going so far to say losing all trust in github.. there was a bug, it's fixed and they suspended the "attacker". I wonder what will happen in the following days with script kiddies trying to "hack" all rails website. In fact, isn't the overloading of parameters something as old as the earth that security experts would check first as a vulnerability?
chrisacky 15y ago
This is a perfect summary and exactly the sentiments that I couldn't express in the article. I've quoted you with attribution if you are okay with that?

deleted 15y ago

[deleted]

mkramlich 15y ago

I'm not too worried about the ability of an attack to push a commit, or cause a commit/object deletion in a repo's history, on GH, because most smart folks (if not everybody, by default) will have multiple copies of a repo across multiple machines, with backups, so anything can be undone or restored. (And trust me, I have the imagination to understand how an unauthorized commit/push could lead to a situation enabling remote execution on client machines who've pulled down tainted commits. Think build scripts that have "install rootkit/malware/keylogger" commands added to them in the mal commits.) What would be more bad is if this vulnerability allowed an attacker to get unauthorized read access or pull/clone access to a private GH repo. Can anyone clarify for me whether this was possible?

jtchang 15y ago

The one "good" thing that comes out of this public exploit is that github was the target. Github is obscure enough to non-developers but quite well known in the development circle. This means if you are using github you probably have a damn good idea what the vulnerability is. I'm not a rails developer (mostly python/django) but I get it immediately. This is mostly an issue with the framework helping me shoot myself in the foot. Sure it's in the documentation. But realistically a good framework gives me sensible defaults so I don't have to refer to the documentation. I trust the framework does the "right thing".

deleted 15y ago

[deleted]

deleted 15y ago
[deleted]

alinajaf 15y ago

Though I will say that mass assignment is about as rookie a rails mistake as you can make, I won't be leaving github. They've delivered so much value over the past four years for me that I can forgive them this and I'd still have (a little) goodwill towards them left over.

colinmarc 15y ago

+1 for the usage of "github-gate."

spqr 15y ago

That's a shame. Sincerely, a .NET developer.

latetothepatty 15y ago

I used GitHub and I'm not moving my stuff off. If an app gets hacked, then not long after, that app will likely be the most secure place. GitHub at least keeps it up most of the time. Who you really should be mad at are the Rails maintainers and the RoR community. I switched from Java to Ruby a few years back, and since day one, everyone using Rails has been slack on security. The reason is that they make things too easy to leave wide open. Don't believe me? Read the Rails official documentation for starting off. It is all about ease of use, not security. If you are new, you have no idea what you've really left open even when you just generate a scaffold as they show you to do. The main thing that Rails security has going for it is that the adoption of Rails is still relatively low, and because a newbie isn't likely to scale their app well, odds are you won't have an extremely popular, extremely performant Rails app that is just asking to be hacked that easily.

tlianza 15y ago

I'm not sure if everyone noticed the last comment on this article: http://screencast.com/t/Nobted7zv5z http://screencast.com/t/Nobted7zv5z Posted "almost 8 years ago" ie. posterous would appear to have the same vulnerability.

mofey 15y ago
Isn't that Twitter?
deleted 15y ago
[deleted]
zedshaw 15y ago
Ha! Alright he probably should quit doing that before he gets KimDotcom'd.
- getsat 15y ago
  Russia has no extradition treaty with the US. He's fine.

knodi 15y ago

This is the first thing in securing your rails app a developer learns, how to properly handle mass-assignment. I don't blame rails, I blame Github.

javascriptlol 15y ago
A system that is designed to rely on human diligence is inherently flawed. It's a mercy that drills and other dangerous tools aren't designed in the same way that a lot of software is.
- unimpressive 15y ago
  Exactly. This is like saying that it was fine for older versions of windows to broadcast the users directory tree over an open file server because they should know better than to leave the server up. (This happened right? Correct me if it didn't.) It's like no, you should have to turn the server on in the first place. The fact that it took some Russian kid in his basement breaking into the github rails master for this self evident truth to be realized by the core rails team is totally outrageous.

eli_gottlieb 15y ago

Oh, they've let you all down? Then stop using other people's web applications and just run your own git/hg server. With blackjack, and hookers. You are vulnerable to someone else's fuck-ups as long as you insist on giving up control over your data and code in exchange for the convenience of someone else doing the "hard work" of development and administration for you. Hell, restore the network to being peer-to-peer rather than hierarchical, and hosting your own whatever will no longer be such a damn problem.

n8agrin 15y ago

There is so much bombastic talk in this post. This has to be a troll.

raganwald 15y ago

As Zed Shaw pointed out, someone appearing to be Homakov has posted a comment dating back eight years. Is Posterous vulnerable as well? If so, that may not be Homakov, of course, but his twitter comments are consistent with him posting it. https://twitter.com/zedshaw/status/176497720817762304 https://twitter.com/zedshaw/status/176497720817762304

jsnell 15y ago
Yes, one of Egor's comments in the github bugtracker had a small (but presumably not exhaustive) list of other vulnerable sites. It included Posterous.

trotsky 15y ago

Jesus, HN goes from zero to lynch mob faster than reddit these days. Guy drops a zero day on a major service provider, guy gets his account suspended (temporarily, it turns out). In what possible world is disabling an account that has recently exploited your live product in a very visible way not ok? Remember, you don't have a chance to call a meeting with the C level guys and your community manager - you're one or two guys responding on a weekend. The rest of the "oh my god the sky is falling" drivel about how terrible a bug it could have been and how they should never have had such a vulnerable bug in the first place is even worse. Security bugs are fuckups by nature - nobody sat and said well shit I was going to code this wrong but since it might allow a lot of access I won't. In terms of OH SHIT bugs this is actually rather small - I'm sure github's live infrastructure has been open to lower level remote execution vulnerabilities over the years - newsflash: we all have been. Getting user or superuser or db admin is going to almost certainly be a lot worse than an application authentication level vulnerability. You say none of that matters because it's such an obvious bug and people have known not to do that kind of thing for years? Say hello to our old friends "buffer overflow" & "use after free" - still grabbing msft aapl & goog after all these years. TL;DR - stop acting like children.

reidmain 15y ago
Correct me if I'm wrong but this wasn't a "zero day". This issue was brought up four days ago https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228
- trotsky 15y ago
  I thought there were two different issues, though not being a rails jockey I could easily be mistaken. Even if it was disclosed four days before it was exploited I stand by my take if not my terminology.
  - masklinn 15y ago
    > I thought there were two different issues Nope, this bug is exactly what he used for his demonstration (and there are warnings about attr_accessible going back 3 or 4 years, so it's not a "0-day" by most accounts, more of a "3-years"" vuln)

ggwicz 15y ago

Shut the fuck up. How many companies get hacked regularly like this but keep it under the rug? You think FaceBook's never been exploited? TurboTax? Mint? Stripe? PayPal? Shopify? Tumblr? Pick your app that "so so so so many businesses" use regularly, and I guarantee something like this has happened with all of them. But were they open about it? GitHub's been open the whole time. Your post is like saying "All criminals are stupid". This is ridiculous, as the only sample you know of and can work with are the criminals who have been caught. You don't know how many other criminals are out there getting away with their crimes, because...they haven't been caught yet. Who knows how many other companies have had hacks like this in the past two months alone, for example? I don't, and neither do you. But GitHub, as an open, honest company that so so so many of use regularly (which means we know right away when there's a problem, especially with a hugely popular repo like Rails/rails) has been in the spotlight since the second this happened. GitHub, in my opinion, has acted really cool about this. They addressed the issue, explained what the issue is, patched the hole, and even reinstated the hacker's account. DHH addressed the issue in twitter, other people in the community have admitted they fucked up, and now we as a community can work on fixing this. That doesn't sound like "Letting us all down". Someone who expects everything to work perfectly all the time and have no vulnerabilities is someone will be let down by anything, a pessimist, and stupid. And certainly not worthy of the front page of Hacker News.

aneth 15y ago

The response to this makes me feel that HackerNews is now populated by a bunch of pretenders. This "bug" has been in Rails since Day 1, and any remotely experienced Rails developer is aware of this functionality. You can argue for a different default, but it's not a bug. Github did have a bug and noone knowledgeable about Rails appears to have made even a cursory inspection of the security of their controllers - which is where attribute protection actually belongs, since different controllers and different users change different attributes. Protected attributes is a blunt tool for simple situations, which is why it's not enabled by default. Github had a pretty terrible bug, discovered, and fixed it. They may not have handled it perfectly, but the certainly don't deserve this sort of mon hatred - any competitor you go to is likely to have security flaws as well, perhaps more severe and subtle. @homako didn't just expose the bug in github, he exploited it to make an unauthorized commit to Rails master. His account most certainly should have been at least temporarily suspended as GitHub had no idea what else he might do to prove his point. So basically, most of the comments here are glaringly wrong or ignorant bandwagoning, and it makes me wonder about the accuracy of information here about topics I'm less familiar with. A sad day when you realize all this intelligent discussion you thought you'd been reading about new topics was probably just grandstanding by eloquent fools.

dasil003 15y ago
Normally I respond negatively to this type of post, but you've captured my feelings perfectly. The facts here are nothing that should be blown so far out of proportion. I can't help but detect a hint of schadenfreude at the idea that Rails core or Github are not infallible.
gurkendoktor 15y ago
> Github did have a bug and noone knowledgeable about Rails appears to have made even a cursory inspection of the security of their controllers > Github had a pretty terrible bug > but the certainly don't deserve this sort of mon hatred For all the free fun you can have on github, they are in the business of selling private repositories. What could possibly have been worse than someone finding a bunch of bugs in a matter of days just to prove a point about Rails?

meow 15y ago

For me the sad part is that there is an almost even split between people arguing the right way to bring this issue to every ones notice. I think this is the perfect way to show how serious the issue is and to get more sites to adopt the fix. Exploits like this are worth a lot on black market. They are worth even more if you provide a precious and vulnerable target to go along (github).

edu 15y ago

Posterous is down?

tlowrimore 15y ago

I'm sorry, but this feels to me like an over-dramatized heap of bullshit. First, the statement, "Rails. You clearly messed up." is self righteous bullshit at its finest. Rails didn't mess up; the programmer(s) at Github messed up. No conscientious developer lets the end user mass-assign variables carte blanche. But with that said, _every_ developer messes up every now and then despite their best efforts; some times they mess up in a big way. Secondly, if a user discovered a vulnerability in something I wrote, and they handled it like homakov did, I'd ban the shit of them until I knew for sure that they weren't a threat. Finally, Github handled this exactly the way many companies would handle it: it's called damage control. These guys are really good at what they do, they provide a great service and they offer-up a lot of their tools to the FOSS community.