SMF Development > Applied or Declined Requests

Disable certain admin functions with config file

(1/3) > >>

neothemachine:
Hi,

due to a recent attack on my website which was caused by a session hijacking vulnerability and the ability in the forum (it was vB) to download database backups, I want to bring this topic up here.

In SMF, permissions can be set for every user group -- except admins. Why?

In my case, database backups happen on a regular basis through separate cron jobs and direct access to the database. The equivalent function in SMF isn't needed at all. So why don't allow to disable it for admins, too? No software is perfect and security vulnerabilities can appear quickly. Should the attacker steal the session or otherwise gain admin permissions, he could download the whole database in seconds. This is an attack vector which can be prevented quite easily.

I guess it doesn't make sense to store admin permissions in the database, but rather in the config file.

What do you think?

Cheers
neo

:
Because administrators are physically hard-wired to have every permission, is the basic reason. It's actually the first line of the allowedTo() function, if they're an admin, return true because an admin has every permission.

Firstly, if it were permission based, an admin would be able to go back in and re-enable the permission anyway thus defeating the point of making it permission based. No point in disabling a permission for yourself when you're entirely able to turn it back on anyway!

Secondly, admins are required periodically to re-validate their session when going into the admin panel, so even if the session were compromised, they'd have to do it within the tight window where an admin is in the admin panel anyway...

Lastly, the reason it's even provided in the first place is because a lot of hosts didn't use to provide phpMyAdmin (or cron jobs etc. on better hosts - remember a LOT of SMF users are running on low quality shared hosting where cron jobs may not even be an option) and when it was developed (it's been in SMF for *years*) it was much more necessary than it is now.


Now, considering the context of the request... disabling it with a configuration file... there's nowhere in SMF that is suitable for storing that, and in most cases with SMF, frankly, that's not really a big deal. Most SMF installations leave files writable for installing mods, it would not be hard to escalate something there to make that an option even if a 'configuration file' disabled it.

*shrug* I would just remove it and be done with it personally, it isn't the issue it used to be, the current backup is buggy and using phpMyAdmin or cron jobs is a far far better approach. (This is why at least one of the SMF fork projects removed it entirely.)

neothemachine:
Hi!


--- Quote from: Arantor on June 17, 2012, 02:02:05 PM ---Firstly, if it were permission based, an admin would be able to go back in and re-enable the permission anyway thus defeating the point of making it permission based. No point in disabling a permission for yourself when you're entirely able to turn it back on anyway!

--- End quote ---

That's why I suggested a config file, see below.


--- Quote from: Arantor on June 17, 2012, 02:02:05 PM ---Secondly, admins are required periodically to re-validate their session when going into the admin panel, so even if the session were compromised, they'd have to do it within the tight window where an admin is in the admin panel anyway...

--- End quote ---
Well, sure. But professional hackers have much time :)


--- Quote from: Arantor on June 17, 2012, 02:02:05 PM ---Most SMF installations leave files writable for installing mods, it would not be hard to escalate something there to make that an option even if a 'configuration file' disabled it.

--- End quote ---
Even Settings.php is left writable? I guess it's not, and if it's not, then attackers can't give themselves more admin permissions, even if they got shell access via the unix web user. So, this would be quite secure.


--- Quote from: Arantor on June 17, 2012, 02:02:05 PM ---*shrug* I would just remove it and be done with it personally, it isn't the issue it used to be, the current backup is buggy and using phpMyAdmin or cron jobs is a far far better approach. (This is why at least one of the SMF fork projects removed it entirely.)

--- End quote ---

Well yes, that might be even better. But there may be cases like that for which it might be useful, too.

:

--- Quote ---Even Settings.php is left writable? I guess it's not, and if it's not, then attackers can't give themselves more admin permissions, even if they got shell access via the unix web user. So, this would be quite secure.
--- End quote ---

Oh it gets better.

Settings.php is left writable in most cases (it's where maintenance mode is turned on/off) but any file added by a mod will be owned by the webserver user - as will uploaded themes.

This last part is important: there will be a theme file executed every page load (index.template.php), it will be owned by the webserver and it is directly writable from the admin panel anyway! (There's a theme editing option in the admin panel.)

If they can hijack the admin session, they can override anything you care to put in a configuration file.

I've long known about this sort of issue with respect to SMF's files, and the only way to deal with them is to rethink the entire architecture of SMF from the ground up. I've been slowly working on doing that with respect to an SMF fork whoever it's nowhere near done.


--- Quote ---Well yes, that might be even better. But there may be cases like that for which it might be useful, too.
--- End quote ---

Any user who has control of their setup because they're running on a proper host will also be able to upload phpMyAdmin or similar anyway. Anyone who is on a free host like SMFnew or SMF For Free won't have access to do a backup rendering it moot anyway.

emanuele:
Hello neothemachine and welcome to sm.org!

Additionally, as soon as an hacker becomes admin he could install a mod that gets from the database only the informations the hacker needs instead of everything.

Navigation

[0] Message Index

[#] Next page

Go to full version