4 ms·

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-

by 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.
        cheald 14y ago
        Symbols are interned and never garbage collected, so if you can cause an app to create arbitrary symbols, you can cause it to use up all the RAM on the machine and throw it into swap, effectively killing its ability to respond to requests in any kind of timely fashion.
      - tptacek 14y ago
        It is possible, but not straightforwardly. There isn't a code path I know of that converts param keys to symbols. (I wouldn't have said it was possible unless I had a curl line that did it, for what it's worth.)
        cheald 14y ago
        You're the expert here, but that's really disturbing. Is it fixable?
- Xylakant 14y ago
  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.

by jroes 14y ago

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.
      - cheald 14y ago
        Symbols are interned and never garbage collected, so if you can cause an app to create arbitrary symbols, you can cause it to use up all the RAM on the machine and throw it into swap, effectively killing its ability to respond to requests in any kind of timely fashion.
    - tptacek 14y ago
      It is possible, but not straightforwardly. There isn't a code path I know of that converts param keys to symbols. (I wouldn't have said it was possible unless I had a curl line that did it, for what it's worth.)
      - cheald 14y ago
        You're the expert here, but that's really disturbing. Is it fixable?
Xylakant 14y ago
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.