Disable certain admin functions with config file

[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

[Arantor]

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!

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!

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

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...

Well, sure. But professional hackers have much time

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.

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.

*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.)

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

[Arantor]

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.

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.

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

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.

[neothemachine]

Hi emanuele!

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.

It's funny that you mention that. In fact, our hacker tried to install a vB plugin (some crazy encrypted haxx0r script) through the web forms but he didn't succeed as the it was a TEXT field in the database which can only hold 65k chars and the script was longer. I guess he didn't even see that it got truncated.

But what I'm really saying is: I'd rather only install mods by manually uploading them through FTP or whatever. That's the safest way I guess.

[Arantor]

I'd rather only install mods by manually uploading them through FTP or whatever. That's the safest way I guess.

Funny you should mention that, I know a number of people who've avoided platforms (XenForo in particular) because that was the only way to do things, because it's not as nice as using the web interface.

I started working on a way to upload mod packages but do so only via FTP (through the web interface) so that the package itself would not be owned by the webserver but by the user opening the package, to limit the damage hackers on the server could do, but never finished it. It would meet your requirements as a side-effect, because it wouldn't allow doing anything without the FTP password.

[neothemachine]

I think that could be a nice compromise. But you should always allow devs to manually install mods. I found the approach of Vanilla quite nice. You basically just extract a self-contained plugin folder to the plugins directory and that's it. Then you can enable and disable it through the web interface. This is particularly nice because it plays well with source control systems. I guess this is only possible because they completely rely on a hook-architecture and not actually have "mods".

[Arantor]

But you should always allow devs to manually install mods

With the system I have in mind, no mods are able to touch the main code anyway. Any changes would have to be done manually, because plugins don't have the power.

You basically just extract a self-contained plugin folder to the plugins directory and that's it.

Exactly what I have in mind, but I also want to give the user a way to do it without having to fire up an FTP client, e.g. they're not at home and thus don't have access to their regular FTP client.

I guess this is only possible because they completely rely on a hook-architecture and not actually have "mods".

Yup, as does the setup I have in mind.

[neothemachine]

Sounds great! When you have a first working version out, I'd be interested to provide feedback if you want.

By the way: I hate the captchas in this forum! They're too difficult to read. Did someone consider using reCaptcha?

[Arantor]

Sounds great! When you have a first working version out, I'd be interested to provide feedback if you want.

Well, there's already a working version of most of it, it's a reworking of SMF (a fork) called Wedge. Not too hard to find but because the licence isn't currently a true open source licence (it's SMF 1.1.x's at present, with an extra clause that two particular users we've had the misfortune to encounter are not permitted to use it) it's not really allowed to be discussed here.


Also, reCAPTCHA is not really that recommended either. Apart from the fact that using it here would let people believe SMF has it built in (which it doesn't), the team has always shied away from using third party services. Not that reCAPTCHA's actually that good, the current success-of-first-attempt for humans is about 50% and bots 30% by their own figures.