A user hacked into the official GitHub-hosted Ruby on Rails code repository and bug tracker on Sunday in order to show the Rails development team how serious a vulnerability was.
Ruby on Rails, commonly referred to as Rails, is an increasingly popular Web application development framework for the Ruby programming language, whose goal is to allow developers to focus on building applications rather than understanding what goes on under the hood.
One of the most popular Web services built using Rails is GitHub, a large code hosting and collaborative development platform, which also hosts the official code repository and bug tracker of the Ruby on Rails project.
Last Thursday, a Russian user named Egor Homakov reported a Rails vulnerability that could be exploited to insert unauthorized data into a Rails' application database through Web forms, much like in the case of SQL injection.
The security issue stems from an actual Rails feature called mass assignment, which can be abused if left unsecured. The possibility of abuse has been known for years, but the Rails development team felt that it is the responsibility of application developers to restrict what attributes can be modified through it.
The question is essentially whether Rails developers should take a blacklisting or whitelisting approach with this feature; if they should allow all attributes to be modified by default and expect developers to blacklist the sensitive ones, as it happens right now, or if they should block all attributes by default and ask developers to enable the ones they need after considering the security implications.
However, history has repeatedly shown that offloading security decisions to users is often a bad idea that can lead to a large number of insecure installations, which is what Homakov claimed had happened over the years with the Rails mass assignment.
After unsuccessfully trying to convince the Rails team that the feature should be locked down by default, Homakov decided to demonstrate just how widespread the problem is by showing that not even GitHub, one of the most successful Rails applications, enforces the necessary restrictions.
On Sunday, Homakov exploited the vulnerability on GitHub to create a rogue entry on the Ruby on Rails bug tracker that appeared to have been posted 1001 years into the future. He then gave himself commit rights to the official Rails code repository by replacing the public key of a real developer with his own into the GitHub database.
"At 8:49am Pacific Time this morning a GitHub user exploited a security vulnerability in the public key update form in order to add his public key to the rails organization," GitHub developer Tom Preston-Werner, said in a blog post on Sunday. "He was then able to push a new file to the project as a demonstration of this vulnerability."
GitHub fixed the vulnerability in less than an hour and temporarily suspended Homakov's account pending an investigation into his actions. His account was later reinstated after the GitHub team determined that his intentions were not malicious.
"In parallel to the attack investigation we initiated a full audit of the GitHub codebase to ensure that no other instances of this vulnerability were present," Preston-Werner said. "This audit is still ongoing, and I am going to personally ensure that we have a strategy going forward to prevent this type of vulnerability from happening again."
The incident has attracted a lot of attention and the Rails developers are now more willing to discuss the problem and possibly find a solution. However, now that the vulnerability has gained publicity, the risk of attacks against unsecured Rails applications is higher.