10 ms·

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

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.

jroes 14y ago
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.
- nbpoole 14y ago
  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/rubyonrails-security/DCNTNp_qjFM https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...
rst 14y ago
Different vuln; this one has nothing to do with session cookies.
- jroes 14y ago
  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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5664 It references two articles that require session secrets.
  - tenderlove 14y ago
    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.
    - cheald 14y ago
      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?
      - tptacek 14y ago
        You can get Rails to construct symbols out of a params hash in some cases.
        icambron 14y ago
        Honest question: how?
        kill9 14y ago
        I doubt tptacek will publicly reveal ways to exploit this (or any) vulnerability. EDIT Well... he might, but I've never seen him do it. He's a security professional, after all.
        cheald 14y ago
        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.
        ufo 14y ago
        How is this a DOS vector? Would passing a symbol instead of a string in the parameters cause the app to crash?
        tptacek 14y ago
        No; the theory behind that attack is, Rails doesn't GC symbols, so you could just repeatedly stuff requests that created new symbols until memory was exhausted. I don't care about that attack (there are others like it), but it's viable.

jroes 14y ago

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.

nbpoole 14y ago
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/rubyonrails-security/DCNTNp_qjFM https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

rst 14y ago

Different vuln; this one has nothing to do with session cookies.

jroes 14y ago
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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5664 It references two articles that require session secrets.
- tenderlove 14y ago
  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.
  - cheald 14y ago
    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?
    - tptacek 14y ago
      You can get Rails to construct symbols out of a params hash in some cases.
      - icambron 14y ago
        Honest question: how?
        kill9 14y ago
        I doubt tptacek will publicly reveal ways to exploit this (or any) vulnerability. EDIT Well... he might, but I've never seen him do it. He's a security professional, after all.
      - cheald 14y ago
        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.
        ufo 14y ago
        How is this a DOS vector? Would passing a symbol instead of a string in the parameters cause the app to crash?
        tptacek 14y ago
        No; the theory behind that attack is, Rails doesn't GC symbols, so you could just repeatedly stuff requests that created new symbols until memory was exhausted. I don't care about that attack (there are others like it), but it's viable.