The logout issue is more of a PITA than a security problem. Where the problem lies is if you're logged in as an admin.

Parts of the admin section need to be rewritten due to this exploit. What concerns me is a malicious user can uninstall modules, disable or delete modules, remove menu links and a few other things that have no POST or confirmation to them in the admin section.

POC has been tested on my site by removing menu links and disabling modules.

As a quick fix, add a security check before allowing modifications requested by GET (fix by Biggles!).

Quote::

if ($module_name != $CPG_SESS['admin']['page']) { cpg_error(_ERROR_BAD_LINK, _SEC_ERROR); }

Where should this code be placed? Is there somthing I could grep on or does it go in only one spot?

Also, what about renaming the admin.php to something else? Would that slow an exploit like this down?

thanks safecracker for reporting them
dragonflycms.org/cvs/h...p?b=9.21.2
dragonflycms.org/cvs/h...hp?b=9.5.2

spacebar wrote:

Also, what about renaming the admin.php to something else? Would that slow an exploit like this down?

Yes it will unless they found out the name of your admin file.

Good work, DJ!

Credit for POC, testing and the fix goes to Biggles!

Spacebar --> have a look at the diffs for admin/modules/modules.php and you can see where DJ added similar code.

could this expolit can make users to unsuspened themself?

no noles the unsuspend needs the POST command

xfsunoles wrote:

could this expolit can make users to unsuspened themself?

Nice thought though! Still trying to track down that pesky problem!

DJMaze wrote:

spacebar wrote: Also, what about renaming the admin.php to something else? Would that slow an exploit like this down? Yes it will unless they found out the name of your admin file.

That's a good suggestion too... like any approach to security... there is no one, single thing that will make you secure -- layers will be the most effective!