How A Russian Developer Hijacked Github To Help The Rails Community

This past Sunday, Russian software developer Egor Homakov hijacked the databases of Github, an extremely popular software project hosting and version-control tool, to prove a point. How did he do this, and why? To answer the first question requires some technical explanation, but the second can be answered in purely human terms. Much of Github is built on Ruby on Rails, a widely-used “full stack” web framework written in Ruby, which, as Homakov revealed, had a vulnerability in its architecture and default settings. He took advantage of a mass assignment vulnerability, which is to a Rails application what the risk of SQL injection is to apps built with, for example, PHP and JavaScript. Egor wrote in a blog post from Sunday morning that his Rails hack allowed him to do a number of things on Github. First, he was able to set the date of his comments and posts. He posted from 1,001 years in the future. He was also able to post as whomever he wanted; Egor chose the perpetually drunk robot, Bender, from Futurama as his nome de plume. And finally, he realized he was able to pull, commit and push to any repository on Github. “Jack pot.” [sic] With this power, he could have wiped out whole codebases, version histories and wikis, but Egor instead committed a single file, titled “hacked“, to the master Rails repository. But why’d he do it? Was it just “for teh lulz”? No. Egor did this to help highlight security vulnerabilities in Rails’s default settings, and in so doing, make Rails more secure, right out of the box. A very well-written article from Ars Technica said it best:

It’s a bug that’s so common many users have grown impatient with warnings about them. Maintainers of Rails have largely argued individual developers should single out and “blacklist” attributes that are too sensitive to security to be externally modified. Others such as Homakov have said Rails maintainers should turn on whitelist technology by default. Currently, applications must explicitly enable such protections.

So, it boils down to a difference in opinion regarding how secure, by default, Rails should be. Homakov seized control of Github when he realized his vulnerability report was being ignored, two days after he posted the report.

Why I do this? Since guys in rails issues ingored me and my issue I got spare time to test it on the first website i had in mind. github.

The questions raised by Rails-gate 2012 extend beyond the discipline of software development. Was Homakov acting ethically? It’s hard to say. That he didn’t delete git repositories or do anything more malicious than “troll” Rails maintainers with the “hacked” file is a testament to his motivations—the damage could have been worse. And much of the Rails community (and the software development community writ large) have come to Homakov’s defense. Ultimately, Github found no malicious intent in Homakov’s actions, reinstating his account and clarifying their policies on responsible disclosure of security vulnerabilities.