Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Trailrunner7 writes with the news as posted at Threatpost (based on this advisory) that "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 fix the flaw, versions 3.2.10, 3.1.9 and 3.0.18. 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. The vulnerability lies specifically in the Ruby on Rails framework, and its presence doesn't mean that all of the apps developed on vulnerable versions are susceptible to the bug."

According to the article, this is not in fact a major security flaw, unless you have made your secret session key (HMAC) for the app public, and are using old style finder methods like find_by_id(2) etc. For a start the attacker has to know your HMAC - this is randomly generated when creating a rails app, and is not supposed to be publicly disclosed, though if your app is open source and you forgot to change it and left it in a public repo, it is possible someone could find it. The vast majority of rails apps this is not going to apply to, and there are obvious reasons you shouldn't make your session signing key public anyway.

So it looks like this is a bug which the majority of rails users won't have to worry about, but it's good that they fixed it.

If you publish the key used to sign sessions, people could fake session cookies and log in as someone else for example so this vulnerability would be the least of your problems. It's a problem all by itself, and is not something that is possible to do without publishing your entire app source on GitHub for example and forgetting to hide the passwords/keys which should be kept private (e.g db passwords, hmac). You can't publish it by mistake by misconfiguring your web server for example, it would have to be

Model.where(some_field: 5) is not the same as Model.find_by_some_field(5). The #where method returns a lazily evaluated database request which functions more or less like an array. #find_by_... returns either the "first"* model to match or nil if no models match and is much more useful for one-liners

* IIRC no ordering is guaranteed unless you have an #order portion in your model default scope

Seems like you are mistaken. The very next sentence after the block you quoted says:

There are other exploitable scenarios, but it really depends on what your app is doing. Since it is impossible to prove that something isn’t insecure, you should take the vulnerability seriously and upgrade anyway even if you think you aren’t affected.

Do you feel witty copying my first sentence? In any case, you are correct, I neglected to say "but you need to be using it as your authentication framework". There aren't any others that are noted to be vulnerable that I can find. If you're using your own custom authenticator, there's no reason to have a marshaled hash in your cookie. If someone can provide an example of a custom authentication setup that uses marshaled hashes, please do cite it.

Actually that's not true, since 3.0 at least the default style (from scaffolds for example) has been Post.find(params[:id]), many people don't use dynamic finders at all, as you can use where(...) and scopes instead.

Also, according to the advisory, the HMAC is required, that's really very unusual and important.

Had me freaked out for a second, but then I RTFA (on accident I swear). Nothing to see here, please move along. If they have your HMAC key you are doing it wrong.

"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."

Right, but the HMAC session key is used to encrypt user sessions. Change the key, and all the old sessions become invalid. Your suggestion is akin to saying, after someone stops working at your company, every user of the company's website should get logged out.

Forgive me if this is a silly question, but isnt "sending fake credentials to the front-end app" significantly less worrisome than "can send arbitrary SQL commands to the backend DB"?

It shouldn't really be, because if the backend DB is secured properly, "can send fake credentials to the front-end app" and "can explot the front-end app to send arbitrary SQL to the back-end DB" should be exactly equivalent, since the backend DB should only allow the front-end app's account to do things that the front-end ap

That is one, and probably the most common, attack vector. There are other ways to introduce attack vectors as well, documented under the "Other exploitable scenarios" section. Even if you believe you are not vulnerable you should upgrade.

This exploit arises directly from clever code that hooks function names that don't even exist in the text of the codebase. So instead of find([:id]), you type find_by_id(). If I understand it correctly, the method-not-found exception handler pulls out the symbol from the function name itself and calls find(). This is the kind of crap that Ruby developers think is cool and useful.

In Ruby, you are never coding by contract - you are coding by duck tape. It's an awesome language for throwing together a prototyp

I tried running the exploit but activerecord chewed up all the system memory and the oomkiller took the server down. Luckily my server restart cron script runs every minute so my social media aggregator startup, disruptr.com, is back online.