CVE-2019-12204 Missing warning on install.php on public webroot can lead to unauthenticated admin access
- Severity:
- Critical (?)
- Identifier:
- CVE-2019-12204
- Versions Affected:
- ^4.1.0
- Versions Fixed:
- 4.3.5, 4.4.4
- Release Date:
- 2019-09-24
SilverStripe 4.x projects might contain a leftover installation file (install.php) which can lead to unauthenticated administrative access to the CMS, as well as changing the site database through changing connection details.
Both SilverStripe 3.x and 4.x projects can be created through a web-based installer that is bundled in both the downloadable archive and composer-based installations. When choosing to run this installer, the process will warn you to remove the installer file upon a successful installation. When this step is skipped, a prominent warning in the CMS ensures that sites aren't deployed in this state. New sites who are built on SilverStripe 4.1 or newer, and have used the new default option of a public webroot will have this file located in public/install.php, which does not cause a CMS warning. This puts more responsibility on the developer starting the project to remember to delete this file.
When sites are deployed with this file in place, attackers can create administrative users, and change the database connectivity configuration in a way that can affect other visitors of the site as well as CMS users. While there is no known way to reset the website site directly, a user with administrative privileges has access to a large amount of potentially sensitive data in the CMS (e.g. draft content, form submissions).
No user passwords or database credentials (password) are exposed. Projects upgrading from versions of SilverStripe prior to 4.1 are unlikely to be affected due to the prominent warning in the CMS.
Apart from upgrading to the latest supported SilverStripe 4.x release, the easiest mitigation to this potential issue on your site is to remove public/install.php. Note for users of SilverStripe Platform and the New Zealand Common Web Platform (CWP): This issue has been fixed on an infrastructure level already, and does not require a CWP recipe upgrade.
Reported by Steve Boyd (SilverStripe Ltd)
