Rails 2.0 CookieStore insecure after all, because…
In the initial version of my blog post Rails 2.0, cookie session store and security, I concluded that, if given a sufficient complex secret, forging the session data is computationally infeasible. Jamie Flournoy’s comment (see the comments section), as well as this page, turned the tide.
Jamie Flournoy has pointed out that there are flaws in Rails’s secret key generator. The generator is based on the session ID generator in Ruby’s CGI::Session module. Upon investigation, it turns out that CGI::Session’s session ID generator uses a method similar to the one used in Netscape’s SSL implementation in 1995 - which was cracked! So this seems to make it computationally feasible for a skilled attacker to brute force the secret.
I now believe that CookieStore is insecure by default, but the only reason why that is so is because the secret key generator in Rails is flawed. This is something that can be fixed. I believe that, once the secret key generator has been fixed, CookieStore will be secure enough by default. The secret key generator should be fixed ASAP.
I’m now working on a patch that uses /dev/urandom, the Win32 API and/or OpenSSL to create the key, depending on whatever best method is available on the platform.
I have written a script which tries its best to generate a secure random key. It will use /dev/urandom, the Win32 API’s crypto functions, OpenSSL, and plain old rand()+digest, whatever best method is available on the current platform. Download SecretKeyGenerator2.rb
Code from this script can be copied & pasted into Rails’s app_generator.rb.
UPDATE: I updated the script with SecureRandom support.
UPDATE 2: I’ve submitted a patch for edge Rails.
UPDATE 3: The patch has been accepted.
Pratik said,
November 26, 2007 @ 2:09 pm
Umm…wait a second.. http://dev.rubyonrails.org/changeset/7966 is this not supposed to fix that ?
Hongli said,
November 26, 2007 @ 2:14 pm
Ah, I see. That’s great, but the secret key generator in the application generator (app_generator.rb) is still insecure.
And SecureRandom is not installed by default everywhere. It’s not in the Ubuntu repositories, and I can’t seem to find a download website for SecureRandom. The code should fallback to other (still-better-than-rand) methods.
Pratik said,
November 26, 2007 @ 2:19 pm
It’s been there for over a month
Jamie Flournoy said,
November 26, 2007 @ 2:20 pm
>I’m now working on a patch
Sweet! When in doubt, Ruby should always be delegating gnarly stuff like crypto to trustworthy libraries.
>I believe that, once the secret key generator has been fixed, CookieStore will be secure by default.
Sure, from a message-integrity standpoint (can’t forge session data), though not a secrecy standpoint (still can read session contents). But that’s how it was designed to work, so this is more of a taste/paranoia issue than an out and out bug.
Pratik said,
November 26, 2007 @ 2:26 pm
Ah ok. securerandom looks like a ruby 1.9 thingy.
Ben Reubenstein said,
November 26, 2007 @ 6:06 pm
I just spent a long time trying to get SecureRandom working. Is there a simple way to bring it into the 1.8 or should I just wait for 1.9 to come around?
Hongli said,
November 26, 2007 @ 6:38 pm
Just use the code from my script.
Rails 2.0 security « jos442’s blog said,
November 27, 2007 @ 9:35 am
[…] are subject to brute force attacks and session replay attacks. There’s currently a flaw that makes brute force attacks easy, although it should be fixed […]