Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Github compromised, or not?!
Posted Mar 5, 2012 13:00 UTC (Mon) by tialaramex (subscriber, #21167)
The Rails issue does seem larger, and as others have observed has that familiar ring of all the early PHP problems, where there's a feature which "everybody knows" you mustn't use but for some unfathomable reason they can't grasp that this makes providing it a bad idea and it must be deprecated. When even modern C shies away from providing the shotgun loaded, cocked and already pointed at your foot, you know it's time to take these things seriously.
As a github /user/ this doesn't really bother me, any more than when I used to provide source code as tarball dumps from an HTTP server. Git's cryptographic paper trail is impervious to defects in github, Rails, or Ruby itself. If github won't or can't fix it properly, I'll just move the repos somewhere else and continue as before.
Posted Mar 5, 2012 13:51 UTC (Mon) by epa (subscriber, #39769)
It's similar to user testing: you may test your application thoroughly but when you give it to real users they do all sorts of things you didn't expect and will inevitably find bugs. Constructs which lure unsuspecting programmers into opening security holes (even though those programmers are not totally clueless or careless) should be treated as a security bug just as severe as the hole itself.
Posted Mar 5, 2012 13:57 UTC (Mon) by clugstj (subscriber, #4020)
Posted Mar 5, 2012 14:33 UTC (Mon) by sorpigal (subscriber, #36106)
Posted Mar 8, 2012 22:06 UTC (Thu) by bronson (subscriber, #4806)
In this case, just demonstrating the attack is pointless because the docs already say, "don't do that." Homakov needed conclusive evidence that even good Rails programmers miss the docs sometimes.
Posted Mar 5, 2012 14:26 UTC (Mon) by XTF (guest, #83255)
Exactly. How many SQL injection vulnerabilities are the result of PHP's mysql_query() design for example?
Posted Mar 5, 2012 17:27 UTC (Mon) by ajross (subscriber, #4563)
Basically the same stupid mistake. It's a collision between convenience (representing query parameters as variables automatically without the need to explicitly parse/validate/declare/etc...) and safety (forgetting that the resulting variables are potentially from untrusted sources). Rails leans heavily on the DRY principle, and would be expected to be particularly susceptible to this kind of goof.
Posted Mar 6, 2012 8:22 UTC (Tue) by Los__D (guest, #15263)
Posted Mar 9, 2012 12:57 UTC (Fri) by knobunc (subscriber, #4678)
The problem is that it makes it easy to forget to escape the parameters to your queries. Prefer something with placeholders/bind variables.
Posted Mar 9, 2012 13:21 UTC (Fri) by Los__D (guest, #15263)
Posted Mar 5, 2012 14:23 UTC (Mon) by tetromino (subscriber, #33846)
Messing with the rails github was a reasonable action on Homakov's part. He filed a bug explaining that rails was insecure by default. The bug was closed with little discussion ("There was a proposal about changing that flag in #4062 and the consensus is the pros of the default configuration outweigh the pros of the alternative"). So what could he do, as an ordinary bug reporter, to shift the rails core team's established consensus about the default configuration? Further comments would be likely to fall on deaf ears. On the other hand, creating a bug from 1001 years in the future in the official rails bugtracker wouldn't cause damage to anyone, but would have a pretty good chance of convincing the rails core team that their insecure defaults result in real-world problems.
Posted Mar 5, 2012 17:41 UTC (Mon) by aliguori (subscriber, #30636)
He exploited the bug and disrupted a project registered by another user. I'm shocked that they even reinstated his account at all. This was entirely irresponsible especially since for a brief period of time, it was a zero-day exploit that someone more malicious could have exploited.
Had github not responded so quickly, this stunt could have put a lot of people's repositories in jeopardy.
Posted Mar 5, 2012 19:24 UTC (Mon) by PaXTeam (subscriber, #24616)
0-day doesn't mean what you think it does. the bug *stopped* being 0-day (read: exploitable by only those in the know) the moment it was published. and from what i read, it wasn't Egor who introduced the bug in the first place or kept its existence secret for any significant amount of time, so if you really want to place blame for exposing github users to danger then you need to look no further than github & rails devs themselves.
Posted Mar 5, 2012 21:46 UTC (Mon) by aliguori (subscriber, #30636)
The terminology comes from the fact that many hacking groups would wait until patch Tuesday, and then disassemble the patch and create exploits. That means that these exploits would have a short window of time (usually a few days) where an administrator could be apply the fix before being concerned about the exploit.
0-day exploits are out in the wild before a fix is available.
Posted Mar 5, 2012 23:19 UTC (Mon) by PaXTeam (subscriber, #24616)
nope, it doesn't. and quoting wikipedia on it just shows how clueless both you and they are. first, the term '0-day' comes from the warez world where it had a different meaning ('fresh stuff', not released and traded anywhere else before that day, and the wiki is wrong on this meaning too, btw). since the late 90's it was then used for similar (initially) 'fresh stuff' traded among the hacker underground signifying the novelty of the exploit and the underlying security bug (read: unknown by anyone else). unlike a warez 0-day though which loses its 0-dayness after one day (there even used to be terms for 0-hour, etc), a 0-day exploit remains 0-day until either the exploit or the underlying bug becomes public. the Microsoft patch Tuesday has never had anything to do with the term, 0-day predates that event by a decade.
tl;dr: 0-day exploits are about bug/exploit secrecy, not fix availability.
Posted Mar 6, 2012 8:24 UTC (Tue) by Los__D (guest, #15263)
Posted Mar 6, 2012 9:43 UTC (Tue) by epa (subscriber, #39769)
Posted Mar 7, 2012 14:11 UTC (Wed) by pboddie (subscriber, #50784)
Posted Mar 6, 2012 11:50 UTC (Tue) by nix (subscriber, #2304)
Posted Mar 5, 2012 21:28 UTC (Mon) by Wol (guest, #4433)
The bug was already "in the wild". The people responsible for fixing it had said "not a problem". Somebody WAS going to exploit it.
Better a white-hat embarassing the project in public for being stupid, than a black-hat actually pulling off a damaging crack.
I repeat - THE BUG WAS ALREADY PUBLISHED AND IN THE WILD.
Posted Mar 5, 2012 21:47 UTC (Mon) by aliguori (subscriber, #30636)
Posted Mar 5, 2012 18:00 UTC (Mon) by clugstj (subscriber, #4020)
Honestly, the number of people defending this guy worries me.
Posted Mar 5, 2012 19:35 UTC (Mon) by fuhchee (subscriber, #40059)
Your analogy is not working for me.
Posted Mar 6, 2012 0:34 UTC (Tue) by bronson (subscriber, #4806)
GitHub, Rails, and Homakov are drinking in a bar. Everyone in the bar knows that, if you don't whitelist your wallet, Rails will steal it and punch you in the face. This aspect of Rails is well documented and everyone in the bar laughs when stupid noobs come in from the street and get their wallets stolen and faces punched.
Homakov grows tired of the game and tells Rails to quit being so hard on noobs. Rails ignores him, Homakov persists. Rails gets irritated and tells him everybody loves things the way thtey are and nobody really cares -- the only people who get their faces punched are the ones asking for it.
Homakov still disagrees but, since Rails is such a popular guy, he isn't getting anywhere. So He goes up to GitHub, one of Rails's best friends, and punches HIM in the face. Just lightly on the cheek, no damage done, but the point is made. Everybody in the bar is shocked and suddenly feel rather vulenrable... If it's so easy to punch GitHub in the face, then it's easy to punch ANYBODY in the face.
Rails suddenly realizes he's been acting like an asshole and agrees to change. GitHub was angry at first but that passed quickly and he and Homakov are good friends again. Everyone in the bar feels sheepish for pretending that nothing was wrong. Everybody agrees that it shouldn't have come to that but sometimes you're so wrapped up in your own drink that you lose sight of the bigger picture. Once in a while you need a Homakov to shake you out of your complacency.
And everybody lived happily ever after. Does that answer your question?
Posted Mar 6, 2012 1:22 UTC (Tue) by junkio (subscriber, #5743)
Posted Mar 6, 2012 2:44 UTC (Tue) by bronson (subscriber, #4806)
To see some of the complacency that needed to be shaken loose, start reading here: https://github.com/rails/rails/issues/5228#issuecomment-4...
Posted Mar 6, 2012 7:08 UTC (Tue) by scientes (guest, #83068)
Posted Mar 6, 2012 21:27 UTC (Tue) by jnguyen (guest, #72727)
Posted Mar 7, 2012 14:15 UTC (Wed) by pboddie (subscriber, #50784)
Posted Mar 5, 2012 21:10 UTC (Mon) by rfunk (subscriber, #4054)
The discussion in the Rails bug report is probably the best place to get the technical history of this: https://github.com/rails/rails/issues/5228
And the likely plan for fixing Rails:
Posted Mar 5, 2012 21:32 UTC (Mon) by robinst (subscriber, #61173)
And existing applications can enable the configuration option and fix their models to get the secure-by-default behavior.
Posted Mar 7, 2012 11:32 UTC (Wed) by job (guest, #670)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds