3 ms·

You could, hypothetically, move from CookieStore to a different session store, but I am not positive that this will mitigate the vulnerability (by making it mor

by patio11 13y ago

You could, hypothetically, move from CookieStore to a different session store, but I am not positive that this will mitigate the vulnerability (by making it more difficult for the attacker to get write access to the session, not by making it more difficult to turn a session into code execution), and do not have a few hours to reacquaint myself with the code to give you a firmer answer there. I am weakly confident, on the basis of some spelunking in the Rails internals in February, that if you get attacker chosen data into the session you're uniformly hosed on (at least) Rails 2 and Rails 3.

rmc 13y ago
if you get attacker chosen data into the session you're uniformly hosed on (at least) Rails 2 and Rails 3. I wonder if you could expand on this? I'm not too knowledgeable about Rails or security, so I'd wonder how that works?
- patio11 13y ago
  Long story short: If a cookie is valid (HMAC signature matches what you'd expect given the cookie contents and your secret key), Rails (Rails 2) or Rack middleware (Rails 3) will attempt to use Marshal.load(txt) on the cookie contents to populate your session hash. You might naively assume that this creates a map of strings into other strings, but surprise, Marshal.load(txt) can create arbitrary object payloads and, through a code path which the margins of this comment are just slightly too thin to contain, allow you to do remote code execution. See: http://www.exploit-db.com/exploits/27527/ http://www.exploit-db.com/exploits/27527/ This can be done in an entirely automated fashion and requires no knowledge of the application other than the session's secret key.
alinajaf 13y ago
And Rails 4. The difference with Rails 4 is that the session is encrypted as well as HMAC'd, but it's still the case that as along as you have the token (or can otherwise craft a session) you're hosed.

by patio11 13y ago

rmc 13y ago

if you get attacker chosen data into the session you're uniformly hosed on (at least) Rails 2 and Rails 3. I wonder if you could expand on this? I'm not too knowledgeable about Rails or security, so I'd wonder how that works?

patio11 13y ago
Long story short: If a cookie is valid (HMAC signature matches what you'd expect given the cookie contents and your secret key), Rails (Rails 2) or Rack middleware (Rails 3) will attempt to use Marshal.load(txt) on the cookie contents to populate your session hash. You might naively assume that this creates a map of strings into other strings, but surprise, Marshal.load(txt) can create arbitrary object payloads and, through a code path which the margins of this comment are just slightly too thin to contain, allow you to do remote code execution. See: http://www.exploit-db.com/exploits/27527/ http://www.exploit-db.com/exploits/27527/ This can be done in an entirely automated fashion and requires no knowledge of the application other than the session's secret key.

alinajaf 13y ago

And Rails 4. The difference with Rails 4 is that the session is encrypted as well as HMAC'd, but it's still the case that as along as you have the token (or can otherwise craft a session) you're hosed.