The Compromise of GitHub An Ethical Post-mortem
On March 1st, GitHub user Egor Homakov (homakov) posted an issue to the Ruby onRails issue tracker expressing concern about a security vulnerability in the Rails source. https://github.com/rails/rails/issues/5228
After a response by Rails contributor Piotr Sarnacki, the issue was closed without a ﬁx. https://github.com/rails/rails/issues/5228
1001 years from now,Homakov opened a new issue. (You read that right.)https://github.com/rails/rails/issues/5239
He then made a commit (code change) to the Rails master branch, adding a ﬁle stating “github pwned. again. :(“ http://tinyurl.com/7bﬂmnv
Normally, only core team members are allowed to commit directly to a repository on GitHub.In an announcement on his blog, Homakov announced that hehad administrator-level access to every repository on GitHub. http://homakov.blogspot.com/2012/03/egor-stop- hacking-gh.html
Upon recognizing the exploit, GitHubﬁxed the error and suspended homakov. https://github.com/blog/1068-public-key-security- vulnerability-and-mitigation
homakov quickly responded on his blog,recognizing that he ‘behaved like a jerk’http://homakov.blogspot.com/2012/03/im-disappoint- github.html
After reviewing what happened, GitHub reinstated his account.
This vulnerability was the default behavior for all Rails applications.Is it the responsibility of the Rails team to their users to choose secure behavior by users? Consider http://tinyurl.com/6qwr4s7
Homakov brought up the issue well in advance of actually using the ‘sploit. Did he overstep his bounds? Is unsolicited ‘white hat’ hacking okay?
After the fact, many users were very concerned that GitHub had failed to protect the security of its users.The mass assignment bug is a known (if somewhat obscure) vulnerability in Rails. Did GitHub drop the ball by not securing their application against this exploit?