[OJS 3] How secure is the upgrade process?

Hi! We have some concerns regarding a certain stage in the upgrade procedure, when we open a web browser to the OJS site and get redirected to the installation and upgrade page.
There is a slight chance, that any other user at this stage might ‘recapture the initiative’ and do something unwanted (either deliberately or by mistake).

So the question is how secure this procedure is, and how it could be optimized?

1 Like

Using the command line upgrade is the best option, both in terms of minimizing end-user impact and in avoiding web-based timeouts and process limits.

If you do need to use the web-based upgrade because you have no access to the command line tools, it would be best to configure your webserver to temporarily restrict access to the general public. For example, in Apache you might redirect all traffic not from your IP to a static “maintenance” page.

If an end user does see the installer or upgrade page, this provides them with the opportunity to try to click through the available options. That is obviously undesirable, but not a particularly exploitable “security” concern. The install screen does expose your version of PHP, the writable status of some directories and files. This form could be used by an attacker to try to guess a database username and password. Someone with a valid database username and password could create a default OJS database. Probably the most problematic exposure of this form would be the ability of a naive or malicious user to overwrite your existing config.inc.php (if permissions allow) with a default version.

1 Like

Thank you!

Yes, but when we change “installed = On” to “installed = Off”, the upgrade page becomes available anyway. Even if we choose to use the command line.

Using the command line to update, you do not need to change the config.inc.php installed setting. Just leave it “On” and run php tools/upgrade.php check|upgrade directly.

1 Like

Ah, now I see… Then I suspect the instruction in docs/UPGRADE needs some editing:

  1. Command-line

If you have the CLI version of PHP installed (e.g., /usr/bin/php), you can
upgrade the database as follows:

- Edit config.inc.php and change "installed = On" to "installed = Off"
- Run the following command from the OJS directory (not including the $):
  $ php tools/upgrade.php upgrade
- Re-edit config.inc.php and change "installed = Off" back to
   "installed = On"
1 Like

Hmmm… calling in assistance here.

@asmecher, I have never followed the instruction of turning installed “off” for CLI upgrades. This was added with a reference to bug 8436, but 8436 doesn’t turn anything up in bugzilla.

Is the intent here simply to lock users out of the site during the upgrade run?

That’s a mistake. We also never followed that instruction and all is OK

I think the instruction is just being used as a way to set the site into a pseudo “maintenance mode” for the upgrade, but without seeing bug 8436, I can’t be sure.

@Vitaliy, @ctgraham,
And what the end user is supposed to see when we run php tools/upgrade.php upgrade without setting "installed = Off"?
Would some “maintenance mode” page appear then?

In an ideal scenario, end users would see an actual “site maintenance” page during the upgrade process, to prevent any unexpected collisions of user activity with the upgrade actions. This doesn’t exist (to my knowledge) in OJS yet.

In my case, I just plug out internet cable and run upgrade script directly from server. But, obviously, this can’t be done on hosting

1 Like

I agree that a blank page with some message displayed during the upgrade process would be ideal. However, if there is no such page, this might have been the reason why @asmecher could insert the recommendation about setting "installed = Off".
But this again gives us the page, which is not entirely secure. This might be quite important for installations, which are highly loaded (accessed frequently). So I really hope, @asmecher might clarify more on this.

Hi all,

Unfortunately our Bugzilla archive is temporarily offline (we’re working to create a read-only image so we can stop hosting the application, which occasionally attracts spam) so I can’t check the reasoning. But I don’t think there’s anything major currently in the codebase that reacts differently when upgrading with the CLI tool depending on whether Installed is Off or On.

As for the security of the upgrade process, I tend to run test upgrades on cloned installs before I upgrade in-place, so the actual upgrade is very likely to complete successfully and in a minimum of required time. Then I edit index.php and add a die('This system is currently undergoing maintenance.'); statement to the top of the file, run the tool, and remove the statement.

This is effectively equivalent to adding a maintenance mode, and is a one-liner, so I haven’t really seen much benefit to adding another more formal configuration setting and checking it on every request. But that’s a selfish way of approaching it and I’m open to contributions and ideas to improve this!

Alec Smecher
Public Knowledge Project Team