Hi all,
I just discovered that we are not, by default, modifying the secret_token that Rails uses
to sign its cookies. (For some reason, the Rails security guide makes no mention of this.)
It is my understanding that, if an attacker knows the secret token a Rails installation is
using, they can modify session cookies however they wish (e.g., becoming an administrator)
and then use the token to sign the cookie so Rails accepts it.
This patch adds a rake task to generate a new token and replace the one in the
config/initializers/secret_token.rb file. It also invokes this task in the %post section
of the RPM spec file, so that it will be re-generated when installing. (I don't think
invoking it from aeolus-configure (in puppet) would be adequate, as it would leave people
vulnerable until they ran aeolus-configure the first time.)
I'm not super-experienced with RPM specs, so someone should review the RPM spec and
make sure I'm not doing anything absurd. Since the rake task is part of the app, it
has to run in %post, since it won't exist in %install. Note that the added
"Requires: rubygem(rake)" isn't really a new dependency. Rails requires it,
but it was suggested that, since we're using it in the spec, we should explicitly
require it.
One small side-effect of this patch is that a user who updates to a new RPM will have
their token regenerated. This would invalidate existing cookies, which will cause users to
be logged out. I think this is perfectly-acceptable and possibly desirable, but if you
disagree, we could change the rake task to look for the specific default token and only
replace that.
We may want to backport this change as I believe this vulnerability has existed from the
beginning.
-- Matt
Show replies by date