Slashdot Mirror
GitHub Hacked
MrSeb writes "Over the weekend, developer Egor Homakov exploited a gaping vulnerability in GitHub that allowed him (or anyone else with basic hacker know-how) to gain administrator access to projects such as Ruby on Rails, Linux, and millions of others. GitHub uses the Ruby on Rails application framework, and Rails has been weak to what's known as a mass-assignment vulnerability for years. Basically, Homakov exploited this vulnerability to add his public key to the Rails project on GitHub, which then meant that GitHub identified him as an administrator of the project. From here, he could effectively do anything, including deleting the entire project from the web; instead, he posted a fairly comical commit. GitHub summarily suspended Homakov, fixed the hole, and, after 'reviewing his activity,' he has been reinstated. Homakov could've gained administrative access to the master branch of any project on GitHub and deleted the history, committed junk, or closed or opened tracker tickets."
That's what you get when you allow Italians like this guy on America's internet. Don't say I didn't warn you.
The remedy is that we all need to be more proactive about patronizing Wisconsin cheese and California wine.
UNITE with the Campaign for a Free Internet because today, our future begins with tomorrow!
Oh wait.. this is an open source community that understood what his intentions where and didn't have a knee jerk reaction. What I guess intelligence trumps mass panic and ignorance.
Well this is an ironic situation. Good thing he had good intentions lol. I find it funny that since this guy hacked github and they fixed it. But seriously, shouldn't people hire hackers like him to make projects move faster ? l Sincerely believe that if they "work" together, projects would move faster for sure lol.
I think it's time to think about repository for strategic software, like Linux, GCC and so on.
Such a hacking can compromise a large part of the internet. Because someone can introduce backdoors, the nasty ones I mean, so deep to evade any check.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Fortunately, git is a distributed version control system, meaning that, usually, there is a copy of the sources and history information elsewhere.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
...as if millions of voices suddenly cried out from coffee shops in terror and were suddenly pwned. I fear something terrible, and totally predictable, has happened.
Just wait a few years, Ruby on fails will strike back!
What's GitHub?
This guy is very good example of what the real hacker is, and what they should be. Kudos man.
github paid accounts can have private repositories.
Do you even lift?
These aren't the 'roids you're looking for.
Words change. Either move on with everyone else or be left behind.
Your choice.
Gone!
In this situation, the term hacking is the correct usage of the term. As per your posted link,
"Hackers will sometimes do questionable legal things, such as breaking into systems, but they generally will not cause harm once they break in."
Homakov only made superficial changes to allow him to commit a snide remark to illustrate and publicize the inherent weakness in a cloud storage system used by many independent developers and commercial entities.
In almost any other situation I would side with you on the horrible misuse/overuse of the term "hacking".
That could've gone a lot worse...and to think many stupid countries are trying to make such benevolent activities illegal.
"When information is power, privacy is freedom" - Jah-Wren Ryel
the inherent weakness in a cloud storage system
You may want to look at what he actually did. The problem is people who don't understand "mass assignment protection" dumping rails apps on the internet with CRUD functionality and "sensitive" portions of the data.
There's an inherent conflict between just being able to scaffold something up "instantly" and keeping certain attributes locked away from the average users, and this inherent conflict has never been decisively resolved. Any time you have a tool that makes it easy to CRUD, you're going to end up with people going too far and not protecting anything. Going crazy and locking it down is just going to make the 99% of users who don't need it fork, and the 1% who do need it only putting in enough effort to re-open it.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
So, somebody hacked into a computer system to gain access to open source software. Brilliant.
If you can't imagine a way that unfettered access to *alter* an exceptionally popular piece of software, virtually undetected, would be useful to someone with unscrupulous intent, then good for you for being so pure of heart. However, in the rest of the world, access like that can be absolutely devastating.
Looked more like that showed a vulnerability on it.
The real danger are the ones that could had been exploiting it and didn't announced that... and then, modified some obscure core component in a not very monitored repository to introduce a trojan or backdoor into some widely deployed open souce software based on it (i.e. not sure if that problem would make able to mask a commit as one from a trusted and active developer)
Apparently GitHub's own admin isn't "pro" enough...
Matt Damon
Aliens.
Fortunately, GIT itself, which is a replicated central code revision system, isn't vulnerable to single point repository attack. Thus, he could've injected something, but *any* of the developers would've noticed when they tried to sync local and remote repos. (In fact, this is probably how his commit was discovered.)
So, for all you worry-worts complaining about possible code injections into src, there shouldn't be anything to worry about.
That is rather easy to answer. Git is a distributed version control system such that you can't make changes without it being noticed by the real authors. See ... http://git-scm.com/about ... for a better explanation. To get something malicious into the code you will need to get into the primary lieutenants source trees.
The master branch isn't on github, if there was any tampering a trivial check against Linus' master branch would see if there'd been any extra git commits. Nobody has to go through more than that. By the way, it's also impossible to insert an "old" commit in git because you'd have to reapply every subsequent patch and all the ids would change. But I guess that you're scaremongering and the mods are either clueless or feeding the troll.
Live today, because you never know what tomorrow brings
Not with git.
Git is designed from start make any such messing with the source code instantly evident. That's because every developer has a full copy of the source code _and_ history, cryptographically signed. So if anybody changed a comma in any file it will be _immediately_ evident. Much more than a red cloud around you in a public pool. It also makes losing the history of the code virtually impossible (I mean git, not the red stuff around you).
The real danger was the people who knew of the vulnerability for quite a while and did nothing to fix it.
At this point this is practically a troll.
The battle is over and we lost. Insisting on differentiating between hacking and cracking is just silly now. The word never caught on and never will.
If you can't imagine a way that unfettered access to *alter* an exceptionally popular piece of software, virtually undetected
I can't imagine a way to do that with git. Sorry, its just pretty hard to do, especially "virtually undetected". git just doesn't work that way. Probably a hell of a lot easier and more likely to succeed and frankly cheaper to get commit rights "the right way" and then sneak in 100 perfectly legit real world commits and just one with an intentional bug or issue or whatever. Now, if by "... alter ... popular ... software.." you mean something like modify the github site and user provided data itself to point to some images on some .ru domain that include yet another drive by MSIE exploit, sure that could probably have been done. But the git hosted projects are basically safe, assuming anyone is actually using them.
Which brings up an interesting attack vector, if you find generic abandoned mp3 player number 2352 on sf or github and "take it over" by whatever means, then you could put weird stuff into it without anyone noticing since no one git pulls it. This could be a problem.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
It is not troll. A spade is always a spade, whatever else you may want to call it.
There are 2 types of people in the world - those who understand decimal and those who don't.
Thankfully, no serious projects are hosted on GitHub.
Kill all hipsters.
That's idiocy on the part of the submitter. Linux is mirrored on github, and it was the authoritative repository for a while after kernel.org was hacked, but now it is not the authoritative repository and patches from there will not be pulled into the official tree unchecked.
I am TheRaven on Soylent News
Ruby on Rails - the perfect blend of poor performance (Ruby) and gaping holes (Rails).
Let's call it what it is, Anti-Social Media.
OK, the blog is slashdot'd at the moment, but lets see if I have this right. Basically, you take an active record and just copy values from the POST data into it and then save it ... and this is the default behaviour? Do I have that right because, is so .... .... dear god, what were the ruby-on-rails people smoking when they thought that was a clever idea, its puts ROR on a level with PHP and its magic global variables. Note only that, but what were the github people smoking, the same? Using an insane facility is doubly insane.
Methinks a lot of people need to go and read some web design stuff and realise that active records (or models - django users take not) are not synonymous with the "Model" (business logic) in MVC.
Indeed, I know a few people who are working on some commercial software with one. This is kind of a big deal (although the risk that someone made subtle alterations to say, the Linux kernel, is also a very big deal).
This was brought up when kernel.org was compromised last year. The decentralized nature of git makes that really hard to sneak by, especially if you use the kind of process controls that the Linux kernel uses. Legitimate commits go through maintainers, and maintainers will definitely flip if they see code pulls into their repository that they didn't commit. Some deeper discussion about how you can't just sneak things into the past history is here: http://security.stackexchange.com/a/6771/836
SIG: HUP
"Over the weekend, developer Egor Homakov exploited a gaping vulnerability in GitHub that allowed him (or anyone else with basic hacker know-how) to gain administrator access to projects such as Ruby on Rails, Linux, and millions of others.
Linux??? Can we mod summary as troll? Linux has its origin repository in kernel.org and is distributed over cloned repositories all over the world including my laptop. One can't simply inject a commit into one of those repositories (such as github) and expect it to automatically propagate into kernel.org.
Furthermore, even if you manage to inject a commit into some random project at Github, high are the chances that it would be detected by another developer. Who commits to a repository without reading the commit history?
Now, this Rails vulnerability is rather serious and deserves attention but this article is just plain FUD against github. Congratulations!
At least the message was understood loud and clear... It took a couple of hours and a commit to Rails was made to change the default: https://github.com/rails/rails/commit/641a4f62405cc2765424320932902ed8076b5d38
Who can really go over every line of code in the source to make sure someone hasn't already snuck in something malicious years ago?
Your local repository of git?
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Actually not, if it is a legit commit as Linus... That is the extent he can fake any account...
http://youtu.be/5NNOrp_83RU
Which would be noticed the next time anyone does a push to the repository. There'd be an unexpected non-fast-forward push, and git would force developers to deal with it by default.
Ita erat quando hic adveni.
Always?
-1 overrated isn't the same thing as "I disagree".
Touché! :-)
There are 2 types of people in the world - those who understand decimal and those who don't.
Why do people who gain such knowledge insist on pulling this kind of crap. Why not just attempt to disclose the bug to the site owners and let them fix it. If they refuse, post the info publicly to force their hand. Defacing a project on the site is like a 3 year finding a crayon and looking up and seeing that there's a wall to draw on.
...quicker, easier, more seductive the darkside is...but more powerful, it is not.
When did Microsoft and Oracle start doing Open Source maintenance? Or did the GitHub team download their development principles and follow those instead of doing security reviews?
Both Microsoft and Oracle are notorious for leaving reported bugs open for years unless someone demonstrates an effective exploit using the bug. But historically, Open Source projects have taken such risks seriously and closed the holes long before an exploit showed up.
To me, that "constant maintenance" aspect of open source is it's biggest selling point compared to closed-source products. Not only can people review code and find weaknesses, they can either fix them or submit them as bugs for a project, secure in the knowledge that it will be dealt with.
Apparently that's not the case with all OSS projects. And that's a shame -- because aside from vendor lock-in, this has always been one of the most important "features" that the OSS cognoscenti have preached.
I consider the application of timely repairs and updates so important to security that I built a system whose primary purpose is not to develop initial core application code, but to apply such fixes to all projects under maintenance!
I do not fail; I succeed at finding out what does not work.
I use a Mac (well, my laptop is a mac, at least), and I program in Ada. That's definitely a "real goddamn language".
like facebook? hardly anyone uses that piece of crap.
http://soylentnews.org/~tibman
This guy should be given a medal. It's not often people will take personal risks for the greater good. Even some of those his actions were to benefit the most aren't properly thankful. I tip my hat to you sir.
I'm fairly certain the amount of PHP in your standard Ruby on Rails installation is relatively minor.
This isn't actually a hole in rails.. If you use mass assignment, you need to protect attributes you don't want assigned with attr_protected on your model.
:password => 'hacked'})
:password
If you don't want people to do this:
@user.update_attributes({:favorite_color => 'blue',
You need to do this:
class User < ActiveRecord::Base
attr_protected
end
hardly anyone uses that piece of crap
Half right
Sorry, its just pretty hard to do, especially "virtually undetected". git just doesn't work that way.
So you're pretty safe, unless someone used a hack that gave him admin access over where the source code for git was stored, and might subtly change the way git works so that it's not so safe after all. Oh, wait ...
A successful "Thompson hack" would be devastating, git adds a new vector vector for one, and this is one heck of a scary vulnerability to be ignored by the maintainers (fortunately, they did fix rapidly once this stunt happened - but what happened in the past?)
Socialism: a lie told by totalitarians and believed by fools.
If git itself is hacked cleverly enough, pulling in an innocuous change to the linix source using get also pulls in the malicious code secretly. Someone might catch it by inspection with other tools - or might not! This is why "Thompson hacks" are scary - if you can mess with the basic tools, you can be very subtle.
Socialism: a lie told by totalitarians and believed by fools.
In this case, however, git itself was not hacked. The web interface of github was hacked.
I am TheRaven on Soylent News
The issues is a privilege escalation exploit. Git has no permissions model whatsoever. If you can access a git repo you can do anything you like to it with any name or address you like. Git doesn't care at all. Instead you're supposed to use something like ssh+git, or GitHub or Gitolite etc to act as a gatekeeper and enforce permissions or access to the project. I assume the exploit author figured a way to con GitHub into letting him do anything to the project by bypassing this permissions check in some manner. Perhaps that involves passing a malformed cert, screwing around with cookies or otherwise breaking the permissions in a way that gave him the role he was after to do his commit, or perhaps it was a bug in the admin forms for the website which allowed him to grant those permissions to himself.
Linus (who WROTE git) would probably find it suspicious that a commit he supposedly made to github wasn't present in his personal git tree.
You might be right, but anytime you're relying on the fact that someone will "probably find" something, you're fucked.
But would he actually look at all commits? Nope, hundred, thousands, you gotta trust where its coming from if it said signed off by .
But hey, there's more. We invented a way to make sure "signed off" is _actually_ the person who say they signed off. It's called a cryptographic signature. And it's generally implemented through GnuPG.
It happens that GIT now support per commit GPG signature for this reason (after telling me so many times "oh we don't see the point for implementing it"). Regardless, if everyone signs the commits and everyone checks the signatures locally via a list of people you trust for commits, any other commit will get rejected/you get a fat warning, etc.
The point with this is that you should be able to pull from anywhere, GitHub, a ssh server, anywhere, and be able to trust the commits. Otherwise, distributed development doesn't make sense security-wise. GitHub got "compromised" this time, it will be another host the next time (or them again), there is no "its fixed now".
Bugs exist, bugs are there, bugs will be there too. You just haven't discovered them yet. So, do use commit signing.
To calm any fears that no rogue commits have been added as a result of this hack?
Is git log enough and looking at the last datetime stamp?
Git was written by Linus - the inventor of Lunix. It's a fact that Microsoft Windows is 67% more secure than Lunix which is why do many of my clients gave up on their forays in to Lunix. Yesterday I wiped my last installation of Lunix from my computer. Within 37 hours I was happily running Windows 7, and my glout cleared up. Coincidence? I think not.
Want to stick with Lunix! I'll be by my loving God's side, laughing at you as you burn in Hell. Wait, is this thing on?
But git is stored in git, so to sneak stuff into it in order to break git's security, you would have to break git's security first.
On the other hand, hiding malicious changes in otherwise legit-looking commits is a whole different issue that has nothing to do with github or git.
But git is stored in git, so to sneak stuff into it in order to break git's security, you would have to break git's security first.
With this flaw, couldn't you commit to the git codebase as Linus (or anyone legit) though? Of course, whomever you impersonated might notice.
On the other hand, hiding malicious changes in otherwise legit-looking commits is a whole different issue that has nothing to do with github or git.
Well, you'd need to do this once the normal way to break git, but having done that the 'hiding' part would become trivial (well, with git's tools).
Socialism: a lie told by totalitarians and believed by fools.
Couldn't resist
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
Have you heard the stories about what a huge clusterfuck the Facebook code is?
I am not devoid of humor.
While it's true that it was sloppy coding, it is also true that the default is not really safe - and it probably should be.
In defense of Rails, this isn't a bug, vulnerability, exploit or weakness of RoR its self. The "update_attributes" functionality on a model (which writes new values to a database row) has to be used very carefully. Anybody worth their salt with RoR should know that. If you blindly pass a unsanitized/unfiltered hash directly from the submission from a user to update_attributes, you are definitely asking for trouble and/or are lazy/ignorant at best, imho.
That pretty much summarizes it :P quite funny also, thank you!
everyone checks the signatures locally via a list of people you trust for commits
Somehow this screams "bad idea" to me.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
A commit made on github by Linus is not automatically pulled into kernel.org. It will be reviewed and merged. Most likely someone would say 'Linus, why did you commit here when you are in charge of the upstream repository? That was a strange thing to do' and he would say 'I did not to that, let us inspect the diff and see if someone has done something malicious'. It's pretty easy to spot this kind of thing...
I am TheRaven on Soylent News
This isn't actually a hole in rails.. If you use mass assignment,[...]
No. The problem is that any idiot who thinks he doesn't need to sanitise user input is going to get fucked.
And did.
Watch this Heartland Institute video
I've been spending too much time on Reddit, where 70% of communication is done with memes. (The rest are puns)
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
So if he just told the model that this is a protected attribute, he would have been fine... Its not hard to do this and its a bug like any other bug, not some systematic problem with Rails itself.
So, you'd rather go with a system that uses fail-deadly than fail-safe.
Ok.
Watch this Heartland Institute video
Based on TFA I thought the hack was more about a default flaw with Ruby on Rails key signing, not anything that was specific to github.
Because of its distributed and decentralized nature, it would be very difficult to sneak any changes into a project or its history undetected. Every other copy of the project repo will begin screaming "foul play" when their developers try to sync.
The real question is whether other more nefarious individuals preceded him undetected.