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.
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.
I find it funny that since this guy hacked github
See that's the problem. He didn't hack github. There is a wide open door in scaffolded rails apps. I am somewhat involved in rails development and even I know this, but "most people don't care". The problem in as few words as possible is a lack of input sanitation and/or more or less is the equivalent of allowing SQL injection. Makes for easy scaffolding and rollout. All you need to do is tell rails which attributes people should and should not be able to F with, which is trivially easy and impossible to default without turning rails into a fully cognitive AI system smarter than the programmers who refuse to declare which attributes are sensitive and which are not....
The phrases you don't know to google for are "mass assignment protection" and attr_accessible and attr_protected
http://enlightsolutions.com/articles/whats-new-in-edge-scoped-mass-assignment-in-rails-3-1
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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".
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.
Apparently GitHub's own admin isn't "pro" enough...
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
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
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 is NOTHING like lack of sanitizing or SQL injection.
Suppose your object has fields "name" and "is_special", and the web form only exposed "name" because "is_special" isn't supposed to be changed by regular users. The hacker who knows "is_special" exists, adds an "is_special" field to the web form on his browser and submits it. The developer probably uses "update_attributes" to process the form, and with default Rails settings it will commit the new "is_special" value to the database (properly sanitized, of course).
To prevent this, the developer may switch the settings to white-list, and provide a list of safe attributes for mass-assignment (update_attributes being one of the mass-assignment methods). Some people believe white-list mode should be the default settings. The hacker, probably being one of these people, found a great way to make his point that even seasoned Rails developers could use a push towards using white-lists.
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
Actually not, if it is a legit commit as Linus... That is the extent he can fake any account...
This is NOTHING like lack of sanitizing or SQL injection.
Yes, the act of processing user-supplied data in an unintended manner is exactly what "lack of sanitizing" means.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
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.
He did disclose the publically.
The developers thought it was working as intended.
He hacked the site to show that they're morons.
They patched the issue.
Also, the process of carefully crafting weird http traffic to insert unexpected things is exactly the process for SQL injection, except obviously strange non-developer intended attributes are being inserted instead of "sql EOL character followed by big sql fun" from a classic sql injection attack. Its a very close analogy... The meta-rule that both specific rules lives under is if you're depending on the general internet public to send you something, you can expect someone out there to send you some absolutely crazy stuff and you better be prepared for absolutely anything. If you're not planning on getting UTF-16 encoded XML with embedded COBOL source code for an Intercal interpreter, there's someone in China coding it up right now, so you better get ready for it...
His alternative way to describe how it works and at least one way to avoid it was pretty good, regardless of his analogy analysis skills... I though "as few words as possible" and "more or less the equivalent" was about as wishy washy as I could be when tossing an analogy out there. True, I may have a low /. UID, but I wasn't exactly Moses reading the commandments off the tablets there... And if I was I'd have better commandments than this one...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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
I've barely worked with Rails, but from what you're describing, isn't this bug somewhat like the security problems with register_globals in PHP, which started defaulting to "off" almost a decade ago?
Everything old is new again...
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.
As far as I can tell, the entire point of update_attributes is that it's easy to pass unsanitized data directly from a user request to it and this makes rapid development of Rails applications simpler. Supposedly pretty much no major Rails applications get this right, so it's not surprising the one hosting the Rails Git repository doesn't either.