Some thoughts on the GitHub Exploit
7 March 2012, evening time
GitHub recently fell victim to a security hole in Rails, the web application framework they use to build their site. A user of their site exploited the security hole and gave himself commit permissions on a repository that didn’t belong to him. I’m sure it was no coincidence that the repository that he chose to mess with was the official Rails repo.
My coworker pointed me to the rogue commit, and a blog post about the security hole. The blog post seemed very familiar. It turned out the article was 4 years old: I had read this very article when it was first published. Since that time the hole had been fixed by the Rails team. You could avoid the hack by toggling a setting when configuring your project. The developers at GitHub didn’t do this.
This story illustrates two problems.
Rails is all about convention over configuration. Rails developers often mock the XML heavy nature of J2EE web applications. (And to be fair, J2EE is in fact ridiculous.) That Rails usually just works without having to mess around with a bunch of settings files is part of its appeal. This leads to the first problem this exploit illustrates: software should be secure by default; that should be the convention here.1 When this hole was fixed, the Rails developers should have required developers explicitly ask for the older exploitable behaviour. Still, I can see people arguing that it’s not Rails’ job to make sure developers code securely. So, let’s set that aside.2
The second problem this illustrates is by far the scarier of the two. It’s not amateur hour over at GitHub. As far as I can tell they are amassing an army of bad-ass super-programmers to build their site. That they fell victim to what is arguably a pretty lame exploit should cast fear in the hearts of all developers. Developing secure software is a very tricky problem. You can be very good at what you do and still forget to worry about that one key thing. If only there was a solution for that.3
—
1 It’s a shame the Secure Web Application Framework Manifesto never went anywhere. It probably needed a better name.
2 There are two reasons I can imagine for why the exploitable behaviour was left as the default behaviour: one, to avoid breaking existing software when upgrading Rails; two, because it means you need to type more to achieve the same results—security be damned. Neither answer seems that satisfying. Rails upgrades seem to be trials by fire as it is, and typing never killed anyone.
3 But wait, there is! And that’s what they call a sales pitch.