Revolution: Make MODX Setup safer and inaccessible to non owners

[donShakespeare]

Why is it needed?

1. Prevent someone from overwriting/hijacking one's site.
2. Users like myself often keep the setup folder around (renamed of course) due to the hassle of getting a new setup folder in order to rerun upgrade to clear out some database/path glitch.
3. Many users (as it will continue to be observed - for whatever human reasons) will uncheck the option that auto deletes the setup folder - oh and will ignore the only single Manager Dashboard warning.
4. In case the Server glitches and just refuses to honor the installation's request to delete the setup folder.

Suggested solution(s)

Solution 1.

Access to setup folder would depend on the presence/absence of a specific file. See Typo3 for example https://docs.typo3.org/typo3cms/InstallationGuide/QuickInstall/TheInstallTool/Index.html

Best to have the said extensionless file in the core folder so that it can benefit from being outside webroot (e.g not in /setup/ folder).
Maybe:
core/setup/FIRST_INSTALL
core/setup/UPGRADE
core/setup/ADVANCED

The absence of all of these files would render Setup inaccessible.
The presence of any or all of these files would make available the respective installation/upgrade option (applicable to solution 2)

• These files would be manually created by: the admin or automated scripts.
• If any of these files exist at anytime (even during an installation/upgrade), MODX Manager should red-alert the admin with badgering popups on every Manager page (not only on Dashboard - many admins rarely look at this page)

Solution 2.

A cleaner approach, which is implemented by Vanilla Forums: https://docs.vanillaforums.com/developer/troubleshooting/

Setup would be only accessible according to the presence/absence of a clause in the core/config/config.inc.php

<?php
$database_type = 'mysql';
$database_server = 'localhost';

$setup_mode = 'UPGRADE'; // 'FIRST_INSTALL' || 'ADVANCED' 

Solution 3.

Or finally, request an access key upon installation. Automated install/upgrade scripts could do this as well.
The key would have to match that found in core/config/config.inc.php

<?php
$database_type = 'mysql';
$database_server = 'localhost';

$setup_access_key = 'modx23_$5-=5c127639f0ab04a6.79954302+=7&*Th$edz='; // maybe ignore this on first install???

Just a thought ...
Cheers!

[opengeek]

As mentioned in the discussion, I believe a better solution would be to simply write a file when the setup is completed, regardless if it is an install or upgrade. Then it has to be removed before running it again.

[JoshuaLuckers]

This file should be in the setup directory so no extra action is needed for users who do delete the setup directory after installing/updating MODX.

[donShakespeare]

I am afraid for this file in the webroot, for reasons including the fact I have seen all kinds of wonders with users using both the native and custom File Managers.

[sottwell]

Indeed, the less floating around in the site root the better.

[donShakespeare]

I may have meant web-accessible, which includes /setup/

[opengeek]

There is no reason why this can't go in the setup/ directory. It's an empty file. The setup/ is supposed to be removed anyway.

[JoshuaLuckers]

The current htaccess provided by MODX prevents public access to dot directories. It might be a good idea to create a dot directory (instead of a file) in setup/ once the setup process is completed successfully.

[donShakespeare]

Are non-Apache servers somehow covered by the dot directories?

[rthrash]

Trivial to add for NGINX (and still work with Let's Encrypt):

## Disable .htaccess and other hidden files
location ~ /\.(?!well-known).* {
    deny all;
    access_log off;
    log_not_found off;
    retrun 404;
}

Speaking of which, the current htaccess should probably also be modified to enable .well-known, too.

[donShakespeare]

But all of these settings cannot be default for the various unexpected servers people might be running ....

[rthrash]

For people with the skills to run alternative web servers, I'm fairly certain they have the skills to figure this out.

[opengeek]

The .directories issue is irrelevant to this issue.

[rthrash]

I think Joshua was suggesting checking for a dot-directory instead of a file as an alternative approach.

[opengeek]

It makes no difference. Web access to an empty file or empty directory is irrelevant to the point of this issue.

[guyinpv]

If it makes no difference if there is an empty file somewhere, web-accessible, why is this very concept not accomplished by the presence of the /setup folder itself? Isn't that the same difference? When X is present, danger danger! Or when file Y is present, danger danger!

If the setup folder exists, wreak havoc on the admin.

I don't see why there should be any need at all to keep a potentially dangerous setup folder laying around only for convenience.

Not only that, but what if the setup folder itself is compromised because it's been sitting in there for months and was hacked? I wouldn't trust it, I would want a fresh setup folder each time it's needed. Does the setup routine validate its own files to make sure nothing has been compromised? I doubt it, so a fresh copy every time is certainly best.

Perhaps generating the setup folder could be a function somewhere in MODX to download it, or a MODX CLI command to download it?

Also, core/config is meant to be read-only, so it could be a bit annoying to have to open that up in order to edit it and add a config change, just to run setup. So you have a bunch of FTP stuff to do just to pull a reinstall or update. It's very manual.

I wonder if there is not an easier solution to all this?

[donShakespeare]

Of course there is an easier way, we just need to look at what others have been for years, a lot of data to experiment with there.

[donShakespeare]

Okay, as a user/admin, I take full responsibility for forgetting to delete the setup folder or my server not automatically removing it when I opted in for that after install ... and I also agree that I failed at this very basic thing in MODX web development, but at the same time it is pretty embarrassing that this is even possible. After personally seeing a few sites go down in flames, my shock was seriously renewed.

In the announcement https://community.modx.com/t/modx-setup-directory-site-exploit/648 I was hoping to read this (maybe in other words):

hang on folks, now that you are going to do your own simple part by removing that folder, we too are on orange alert and are going to release a patch ASAP, because we consider this one of the worst exploits...

One major difference between MODX Setup and other CMSes' is that for MODX, Fresh Installation and Upgrade are precariously and dangerously on the same page and with the same access. This is uber weird! A lot of other systems have them separate, and Upgrade often requires you to be logged in as an Admin.

In my OP, this distinction is proposed. Is this something worth considering and implementing, the separation at some level?

Cheers.

[JoshuaLuckers]

If I have time I'll prepare a PR with a solution based on the input received in this issue.

[Ruslan-Aleev]

Logically related with https://github.com/modxcms/revolution/issues/10568

[Ibochkarev]

Fixed #14692
@modxbot close