Hacker News new | ask | show | jobs
by clamstar 4915 days ago
You need the contents of secret_token.rb to exploit this (via a forged session). This makes it much more of a danger to OSS projects than to those in the closed source space.

It's not just a SQL Injection vulnerability. With that secret token, you can set any session value you like.

2 comments

This is how I understand the issue as well. Many people in this thread are commenting about massive dangers, but I don't think anyone has bothered to actually read the references in the CVE.

Also, even open source projects typically ensure or recommend that the secret token be regenerated when using in production environments.

I think the CVE description is inaccurate in this case. Check out the Rails security email list description, which never mentions sessions.

https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

Different vuln; this one has nothing to do with session cookies.
tenderlove mentions it has been assigned CVE-2012-5664. This is that CVE:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5664

It references two articles that require session secrets.

Yes, the article does mention session secrets. However, this exploit does not require session secrets. The person who wrote the blog post wrote about essentially two vulnerabilities: session forging and SQL injection.
No, the guy showed a way to to sql injections by using a forged session. The problem is that the sql injection requires a hash with symbols as key and params are stored in HashWithIndifferentAccess which should not symbolize the keys. So to exploit the SQL injection you need a vector that allows you to inject symbolized keys. It might be possible to corrupt the params hash, but I can't think of any at the moment. However, the session can contain any ruby object and thus is a possible vector.
I'm pretty sure that the injection only works when you can forge a session because sessions may contain marshalled symbols, and the dynamic finders only accepted symbol option keys as valid. You can't get Rails to construct symbols out of a params hash. Is this a separate vulnerability?
You can get Rails to construct symbols out of a params hash in some cases.
Seconding icambron - how? Because I've been up and down that code and can't see any way to do it. Frankly, I don't think it's possible, because otherwise you would have a trivial DOS vector into any Rails application.
Honest question: how?