Security Releases
When potential security holes are discovered in SilverStripe's supported modules, we produce security releases to ensure that you are able to promptly secure your SilverStripe websites (check our security release process). All releases are available on our download page, and are announced on our forums (register to subscribe). Vulnerabilities in releases are disclosed here. Please subscribe to our security release RSS feed and pre-announcement mailing list to stay updated.
-
CVE-2019-12617 Access escalation for CMS users with limited access through permission cache pollution
- Severity:
- Medium (?)
- Identifier:
- CVE-2019-12617
- Versions Affected:
- ^4.3
- Versions Fixed:
- 4.3.5, 4.4.4
- Release Date:
- 2019-09-24
Due to incorrectly shared caches between files and page content, CMS users with different permissions for these object types could gain more access than defined by the system. This depends on a specific access sequence, as well as the underlying records having similar characteristics (database identifier). For example, CMS users with readonly access to files, but edit access to page content, could end up with edit access to certain files.
Base CVSS Score: 5.0
CWP Environmental Score: 5.0
Thanks to Serge Latyntcev for reporting this issue.
-
CVE-2019-12245: Incorrect access control vulnerability in files uploaded to protected folders
- Severity:
- Medium (?)
- Identifier:
- CVE-2019-12245
- Versions Affected:
- silverstripe/assets ^1.0
- Versions Fixed:
- 1.3.5, 1.4.4
- Release Date:
- 2019-09-24
An issue has been found where using the Upload PHP API to upload files into a protected folder would set the file's visibility to public, rather than respecting its parent folder permissions.
The silverstripe/userforms module uses this logic to upload files. Folders can be configured by CMS users to be access protected, either through the optional silverstripe/secureassets module in SilverStripe 3.x, or through core functionality in SilverStripe 4.x. If a form has been created in the CMS with an upload to such a protected folder, uploaded files were not protected from public access.
Accessing the files would require knowledge of the exact file URL, which is further complicated by the content hash added to each URL before SilverStripe 4.4 (with legacy_filenames=false). Since file URLs aren't listed by default, this reduces the overall impact of the issue.
In addition to applying the patch, files which have already been uploaded to assumed protected folders through userforms will need to be re-protected. This can be achieved by saving the protected folder in admin/assets, which will re-sync files on the filesystem into the correct place (assets/.protected). This workaround is only applicable for folders with a small number of files. For large amounts (many hundreds or thousands), we recommend writing a custom task. Silverstripe will provide a built-in task to remediate this situation in an upcoming hotfix release.
Base CVSS Score: 5.9
CWP CVSS Score: 5.9Thanks to Nicolaas Thiemen (Sunny Side Up) for reporting this issue.
Update 03/03/2020: Revised CVSS from 3.7 to 5.9, added workaround description
-
CVE-2019-12205 Flash Clipboard Reflected XSS
- Severity:
- Medium (?)
- Identifier:
- CVE-2019-12205
- Versions Affected:
- ^3.0, ^4.0
- Versions Fixed:
- 4.3.5, 4.4.4
- Release Date:
- 2019-09-24
Third party library code included in silverstripe/framework (3.x) and silverstripe/admin (4.x) packaged their own documentation, which in turn included a vulnerable SWF file. This file was accessible on SilverStripe websites by default. Older browsers executed SWF directly, and in certain circumstances can expose the document object and associated data (e.g. cookies). Modern browsers often don't bundle or active the Flash plugin by default, or don't allow direct execution of SWF files without them being embedded, which mostly mitigates this vulnerability.
Thanks to Jay Richardson for reporting.
-
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)
-
CVE-2019-12203 Session fixation in "change password" form
- Severity:
- Medium (?)
- Identifier:
- CVE-2019-12203
- Versions Affected:
- ^3.6, ^4.0
- Versions Fixed:
- 3.6.8, 3.7.4, 4.3.5, 4.4.4
- Release Date:
- 2019-09-24
Session fixation attack surface has been identified around the change password form.
A potential account hijacking may happen if an attacker has physical access to victim's computer to perform session fixation. Also possible if the targeted application contains an XSS vulnerability.
Requires victim to click the password reset link sent to their email. If all the above happens, attackers may reset the password before the real user does that.
Base CVSS Score: 6.5
CWP Environmental Score: 6.5
Special thanks to Stephan Boscu & Liam Stein for reporting this issue.
-
CVE-2019-12149: Potential SQL injection in restfulserver and registry modules
- Severity:
- Medium (?)
- Identifier:
- CVE-2019-12149
- Versions Affected:
- silverstripe/restfulserver:^1.0, silverstripe/restfulserver:^2.0, silverstripe/registry:^2.1
- Versions Fixed:
- silverstripe/restfulserver:1.0.9, silverstripe/restfulserver:2.0.4, silverstripe/restfulserver:2.1.2, silverstripe/registry:2.1.1, silverstripe/registry:2.2.1
- Release Date:
- 2019-06-11
A potential SQL injection vulnerability has been identified in the silverstripe/restfulserver and silverstripe/registry modules which may allow specially crafted user input to be executed as SQL statements. All users of silverstripe/restfulserver are affected. Users of silverstripe/registry will be affected if they have had a developer implement the features of the module, since it is not enabled by default.
Users with a Web Application Firewall (WAF) are typically less affected, since they protect against malicious request payloads by default, however we still advise customers to upgrade their versions of each of these modules at their early convenience. Note that the New Zealand Government Common Web Platform has a WAF.
-
CVE-2019-12437: Cross Site Request Forgery (CSRF) Protection Bypass in GraphQL
- Severity:
- Medium (?)
- Identifier:
- CVE-2019-12437
- Versions Affected:
- silverstripe/graphql:^2.0, silverstripe/graphql:^3.0
- Versions Fixed:
- silverstripe/graphql:2.0.5, silverstripe/graphql:3.1.2, silverstripe/graphql:3.2.0
- Release Date:
- 2019-06-10
The code change that implements Cross Site Request Forgery (CSRF) protection on GraphQL mutation queries does not adequately protect users against CSRF attacks on GraphQL endpoints. A GraphQL query formed with a fragment portion before the mutation would bypass the check for determining whether the query is a mutation and therefore the X-CSRF-TOKEN HTTP header is not required to be supplied with the HTTP request.
-
CVE-2019-12246: Denial of Service on flush and development URL tools
- Severity:
- Medium (?)
- Identifier:
- CVE-2019-12246
- Versions Affected:
- silverstripe/framework:^4.0, silverstripe/framework:^3.6
- Versions Fixed:
- silverstripe/framework:4.4.0
- Release Date:
- 2019-06-10
CSRF attack vector has been identified for authenticated users with administrative privileges. Administrators tricked to open malicious URL may trigger unintended maintenance actions.This includes some of the URL Variable Tools such as
?flush,?isDevand?isTest. Another potential target is development admin urls (/dev/*). For example that could be/dev/buildas well as some others provided by SilverStripe add-ons. -
CVE-2019-5715: Reflected SQL Injection through Form and DataObject
- Severity:
- Critical (?)
- Identifier:
- CVE-2019-5715 (SS-2018-021)
- Versions Affected:
- silverstripe/framework:^3.6.7, silverstripe/framework:^3.7.3, silverstripe/framework:^4.0.7, silverstripe/framework:^4.1.5, silverstripe/framework:^4.2.4, silverstripe/framework:^4.3.1
- Versions Fixed:
- silverstripe/framework:3.6.7, silverstripe/framework:3.7.3, silverstripe/framework:4.0.7, silverstripe/framework:4.1.5, silverstripe/framework:4.2.4, silverstripe/framework:4.3.1
- Release Date:
- 2019-02-19
A vulnerability has been identified where specifically crafted user input is executed as SQL SELECT statements in the process of writing this input to a database record. It requires a specific SilverStripe implementation to accept user input for this purpose (e.g. through a contact form which stores messages). It further requires that this record is exposed to the user again (e.g. emailing a copy of the contact form submission). In these situations, data stored in other database tables can be viewed (e.g. draft content). This only affects properties on the database record which are intended to be written through this user input (e.g. a contact form message, but not it’s database identifier).
There are no known exploits for this vulnerability which allow changing database state outside of the intended use (writing input to a specific database record). User input accepted by the CMS is not affected, since those endpoints require authentication. In certain situations, this vulnerability allows exposing of user credentials. These credentials are secured by strong one way cryptography (bcrypt hashed with individual salts), which makes it impractical to gain access by offline attacks against the user’s password.
Both direct assignment on DataObject (update(), setters via method calls, setters via magic methods) and indirect assignment (e.g. Form->saveInto()) are affected.
The vulnerability is related to the DBField classes underpinning the DataObject logic. Most DBField types in SilverStripe 3 are affected. Only the DBYear field type is confirmed to be affected in SilverStripe 4, limiting the impact in our current release line to a relatively uncommon use case.
Projects and modules which have implemented their own custom DBField classes may need to adjust them to override the DBField::scalarValueOnly() and DBField::prepValueForDB() methods if they want to accept non-scalar values. A common example of this are CompositeField implementations. Usually, there is no need to adjust custom code apart from upgrading to the latest releases. Subclasses of the DBCompositeField in 4.x are safe by default.
Our thanks to James Turner (plastyk studios) who responsibly disclosed the issue to us.
-
SS-2018-024: GraphQL does not validate X-CSRF-TOKEN
- Severity:
- Medium (?)
- Identifier:
- SS-2018-024
- Versions Affected:
- silverstripe/graphql:^4.0
- Versions Fixed:
- silverstripe/graphql:4.0.6, silverstripe/graphql:4.1.4, silverstripe/graphql:4.2.3, silverstripe/graphql:4.3.0
- Release Date:
- 2018-12-12
While the admin modules were sending the appropriate X-CSRF-TOKEN header in all requests, the GraphQL server was not validating them, thereby leaving itself open to CSRF exploitation, particularly on destructive operations.
-
SS-2018-020: Potential SQL vulnerability in PostgreSQL database connector
- Severity:
- Low (?)
- Identifier:
- SS-2018-020
- Versions Affected:
- silverstripe/framework:^4.0, silverstripe/graphql:<4.3.0
- Versions Fixed:
- silverstripe/framework:4.0.6, silverstripe/framework:4.1.4, silverstripe/framework:4.2.3, silverstripe/framework:4.3.0
- Release Date:
- 2018-12-12
A potential SQL injection vulnerability was identified by using the silverstripe/postgresql database adapter. While unlikely to be exploitable, we have patched silverstripe/framework to ensure that table names are safely escaped before being passed to database adapters or user code.
-
SS-2018-019: Possible denial of service attack vector when flushing
- Severity:
- Medium (?)
- Identifier:
- SS-2018-019
- Versions Affected:
- silverstripe/framework:^4.0
- Versions Fixed:
- silverstripe/framework:4.0.5, silverstripe/framework:4.1.3, silverstripe/framework:4.2.2, silverstripe/framework:4.3.0
- Release Date:
- 2018-11-07
A possible denial of service attack vector has been identified in the dev/build system controller.
dev/build now has its own URL token, similar to flushtoken, to ensure users are authenticated when running dev/build outside of dev environments.
Reported by Michael Strong (SilverStripe Ltd)
-
SS-2018-018: Database credentials disclosure during connection failure
- Severity:
- Medium (?)
- Identifier:
- SS-2018-018
- Versions Affected:
- silverstripe/framework:^3.7, silverstripe/framework:^4.0
- Versions Fixed:
- silverstripe/framework:3.7.1, silverstripe/framework:4.0.5, silverstripe/framework:4.1.3, silverstripe/framework:4.2.2, silverstripe/framework:4.3.0
- Release Date:
- 2018-11-07
When running SilverStripe 3.7 or 4.x in dev mode with the mysqli database driver, there is a potential to disclose the connection details.
We have blacklisted the sensitive parts of the connection information from being included in dev mode stack traces when database errors occur.
Reported by Dylan Wagstaff (SilverStripe Ltd) and Lukas Erni.
-
SS-2018-007: GraphQL lacks CSRF
- Severity:
- Medium (?)
- Identifier:
- SS-2018-007
- Versions Affected:
- >= 4
- Versions Fixed:
- 4.0.5, 4.1.3, 4.2.2, 4.3.0-rc1
- Release Date:
- 2018-11-07
The GraphQL server used by the CMS is exposed to a CSRF vulnerability that allows attackers to force admins to delete all the files on their SilverStripe installation due to the fact that the deletion request is sent without proper validation of the origin of the request or a CSRF token that prevents such acts.
Reported by Mustafa Hasan
-
SS-2018-017: Possible PHP Object Injection via Multi-Value Field Extension
- Severity:
- Medium (?)
- Identifier:
- SS-2018-017
- Versions Affected:
- symbiote/silverstripe-multivaluefield:^3.0
- Versions Fixed:
- symbiote/silverstripe-multivaluefield:3.1.0
- Release Date:
- 2018-07-26
A potential deserialisation vulnerability has been identified in the symbiote/silverstripe-multivaluefield which could allow an attacker to exploit implementations of this module via object injection.
Support for handling PHP objects as values in this module has been deprecated, and the serialisation technique has been switched to using JSON for handling arrays.
As well as this, a potential XSS (cross-site scripting) vulnerability has been identified and remediated.
Reported by Insomnia Security.
