This is just an FYI, but in the interests of full disclosure you should
be aware that the main Radiant site (http://radiantcms.org) was
exploited on May 15th this year. The attacker added an invisible link on
the homepage to another Web site. At the moment we don’t know if this
was the result of an exploit on the Radiant CMS software itself, or if
the attacker used some other means. In either case the attacker managed
to create an admin user for himself and add his link to the homepage
layout. I was only made aware of the problem late last night and we are
still looking into it.
Has anyone else been the victim of an attack on a Radiant Web site? Can
anyone shed light on how the attacker would be able to do this?
Yesterday, I noticed something in the Radiant code. You are using a
class variable in an observer to store the current_user. Using class
variables in Rails is always bad, because a class is used by more
then one user once loaded in production mode. I experienced a lot of
problems with this in the past.
I can’t say if this might cause the exploit, but the code could cause
race conditions which might give users access to the wrong information.
Edwin Vlieg
Op 23-jul-2007, om 2:02 heeft John W. Long het volgende geschreven:
Before we jump the gun, we have no real idea how the attack was
accomplished. The core team is pouring over the log files to find more
information. I agree that the class-variable thing is kind of bad
practice, but it’s set at the beginning of every request (and Rails only
handles one at a time), so there will be no issue with a race condition.
Can anyone shed light on how the attacker would be able to do this?
If it was anything like the attack on Dreamhost accounts
(http://www.dreamhoststatus.com/2007/06/06/security-breach/) it was
via FTP and it looks like anything resembling an index page for a cms
was hit. My Radiant sites were the only ones that weren’t affected
though.
Erik M.
–
Gravel Road Studios
(857) 222-6852
————————————————————
Q: Why is this email 5 sentences or less?
A: http://five.sentenc.es
Can anyone shed light on how the attacker would be able to do this?
If it was anything like the attack on Dreamhost accounts
(http://www.dreamhoststatus.com/2007/06/06/security-breach/) it was
via FTP and it looks like anything resembling an index page for a cms
was hit. My Radiant sites were the only ones that weren’t affected
though.
Erik M.
It could also be someone who has an account on nicola? Provided that
the database password file is not readable only by the user where the
radiantcms site runs under?
Il giorno 23/lug/07, alle ore 15:44, Sean C. ha scritto:
Before we jump the gun, we have no real idea how the attack was
accomplished. The core team is pouring over the log files to find
more
information. I agree that the class-variable thing is kind of bad
practice, but it’s set at the beginning of every request (and Rails
only
handles one at a time), so there will be no issue with a race
condition.
Ok I undestrood
I only made a thought about the class variable…but now I understood
that it’s not a problem…thank u
This is just an FYI, but in the interests of full disclosure you should
be aware that the main Radiant site (http://radiantcms.org) was
exploited on May 15th this year. The attacker added an invisible link on
the homepage to another Web site. At the moment we don’t know if this
was the result of an exploit on the Radiant CMS software itself, or if
the attacker used some other means. In either case the attacker managed
to create an admin user for himself and add his link to the homepage
layout. I was only made aware of the problem late last night and we are
still looking into it.
Has anyone else been the victim of an attack on a Radiant Web site? Can
anyone shed light on how the attacker would be able to do this?
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:
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
correctly.
I fixed the problem by following the advice of this article:
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!!!
