The ever-popular Web application framework Ruby on Rails has a serious problem: the intersection of security and usability was forgotten by the developers.
Most RoR applications store data in a cookie on the user’s computer. To keep a malicious user from tampering with it, RoR uses a hashed-based message authentication code (HMAC) to sign the data in the cookie. Any tampering gets immediately detected, because the HMAC no longer matches.
Except — what if the attacker can generate the right HMAC? That shouldn’t happen, because you need a secret code, and it’s not like the developer would post that secret code to a public website by mistake, not realizing the file’s supposed to be kept secret. And it’s not like great swaths of developers would do this as part of opening their programming up to others to re-use and improve upon.
Because if such a thing were to have happened, anyone could tamper with the cookies, and not just in order to log in as other people. They could alter the data to “inject” malicious commands into the back-end database on which the Web application was built. This is, of course, the precise technique that the Anonymous types used to breach so many systems in the last few years.
The Ruby developers have released new versions of the framework that fix the problem.
In other news, it’s possible to go below absolute zero:
Wonderful quote on this: “It seems to me that this is very strong evidence for the Simulation Argument,* since apparently the simulation has some integer underflow problems. The researchers have proof of concept code.” (http://emergentchaos.com/archives/2013/01/negative-temperatures.html)
* That we’re all living in the Matrix.
“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.[…]
“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.””