Sylvain Gibier wrote:
Contact me at my email address cptflam [at] gmail.com -
I found the security hole.
Sylvian did indeed find a security hole in the radiantcms.org
configuration. It wasn’t a security problem in Radiant per se, but it
was a problem with the way Radiant was configured on my host. However
the hole it uncovered is something that may affect ANY Radiant
application running on a shared host.
To gain access to the admin pages of radiantcms.org Sylvian used Firefox
2.0 with the Web D. extension which allows you to see the current
cookies for a page. Here is how he got access to the Radiant admin:
He first logged on to the admin part of the demo site:
Then he opened up another tab an initialized a new session hitting
He then changed the _session_id cookie to the value used by the demo
site using the Web D. extension in Fox.
With the correct cookie set he could now bypass the login screen and
hit the following URL:
The reason this worked is that the CGI session stuff is configured by
default to place sessions in /tmp for all Ruby applications. Both the
demo application and the version of Radiant powering the Radiant Web
site were configured to use this default. This effectively meant that
they could share the same sessions the _session_id cookie was set up
I fixed the problem by following the advice of this article:
Which recommended that you place the following line in
=> File.join(RAILS_ROOT, ‘/tmp’))
We will probably be switching to ActiveRecord based sessions to avoid
this in the future. In the mean time, people running Radiant sites
should take note of the above ESPECIALLY THOSE USING A SHARED HOST!!!