All of the current versions of the Ruby on Rails Web framework have a SQL injection vulnerability that could allow an attacker to inject code into Web applications. The vulnerability is a serious one given the widespread use of the popular framework for developing Web apps, and the maintainers of Ruby on Rails have released new versions that fixes the flaw, versions 3.2.10, 3.1.9 and 3.0.18.
Ruby on Rails is a Web framework that’s meant to make designing and deploying Web applications easier and simpler. The open-source framework is used by a wide variety of organizations. The advisory from the Ruby on Rails maintainers says that the problem lies in the way that dynamic finders in Active Record extract options from method parameters.
“Due to the way dynamic finders in Active Record extract options from method parameters, a method parameter can mistakenly be used as a scope. Carefully crafted requests can use the scope to inject arbitrary SQL. All users running an affected release should either upgrade or use one of the work arounds immediately,” the advisory says.
“Impacted code passes user provided data to a dynamic finder like this: Post.find_by_id(params[:id]).”
The advisory recommends that users running affected versions, which is essentially anyone using Ruby on Rails, upgrade immediately to one of the fixed versions, 3.2.10, 3.1.9 or 3.0.18.
Researchers at Phenoelit laid out the details of the problem in late December.
“When a RoR application is created the secret which goes into the HMAC will be created along with all the other files a minimal RoR application would need. This secret usually is a 64 byte long random string and lives in railsapp/config/initializers/secret_token.rb. The simple problem is, that most developers are simply not aware of the confidentiality of this file, and in result they’ll happly check it into Github or other online repositories,” the explanation says.
The vulnerability lies specifically in the Ruby on Rails framework, but its presence doesn’t mean that all of the apps developed on vulnerable versions are susceptible to the bug. The folks at Phusion have a good explanation of the mechanics of the vulnerability and the way it can be exploited.
“The Rails session mechanism allows storing arbitrary Ruby objects, including hashes with symbol keys. Rails provides a variety of session stores, the default being the cookie store which stores session data in a cookie on the client. The cookie data is not encrypted, but is signed with an HMAC [hash-based message authentication cookie] to prevent tampering. The cookie store is fast, does not require any server-side maintenance, and is only meant for session data that do not contain sensitive information such as credit card numbers. Apps that store sensitive information in the session should use the database session store instead. Nevertheless, it turned out that 95% of all Rails apps only ever store the user authentication credentials in the session, so the cookie store was made the default,” Hongli Lai of Phusion wrote in an analysis of the problem.
“So to inject arbitrary SQL, you need to tamper with the cookie, which requires the HMAC key. The HMAC key is the so-called session secret. As the name implies, it is supposed to be secret. Rails generates a random 512-bit secret upon project creation. This is why most Rails apps that are running Authlogic are not exploitable: the attacker does not know the secret. Open source Rails apps however can form a problem. Many of them come with a default session secret, but the user never customizes them, so all those instances end up using the same HMAC key, making them very easily exploitable. Of course, in this case the operator have to worry about more than just SQL injection. If the HMAC key is known then anybody can send fake credentials to the app.”
Users can get the updated versions of Ruby on Rails here.
