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.

• SS-2016-015: XSS In OptionsetField and CheckboxSetField

  Severity:

  Low (?)

  Identifier:

  ss-2016-015

  Versions Affected:

  3.1.19, 3.2.4, 3.3.2. 3.4.0

  Versions Fixed:

  3.1.20, 3.2.5, 3.3.3. 3.4.1

  Release Date:

  2016-08-15

  List of key / value pairs assigned to OptionsetField or CheckboxSetField do not have a default casting assigned to them. The effect of this is a potential XSS vulnerability in lists where either key or value contain unescaped HTML.

• SS-2016-014: Pre-existing alc_enc cookies log users in if remember me is disabled

  Severity:

  Low (?)

  Identifier:

  ss-2016-014

  Versions Affected:

  3.1.19, 3.2.4, 3.3.2. 3.4.0

  Versions Fixed:

  3.1.20, 3.2.5, 3.3.3. 3.4.1

  Release Date:

  2016-08-15

  If remember me is on and users log in with the box checked, if the developer then disabled "remember me" function, any pre-existing cookies will continue to authenticate users.

  Reported by Patrick Nelson - https://catchyour.com/

• SS-2016-013: Member.Name isn't escaped

  Severity:

  Low (?)

  Identifier:

  ss-2016-013

  Versions Affected:

  3.1.19, 3.2.4, 3.3.2. 3.4.0

  Versions Fixed:

  3.1.20, 3.2.5, 3.3.3. 3.4.1

  Release Date:

  2016-08-15

  The core template framework/templates/Includes/GridField_print.ss uses "Printed by $Member.Name".

  If the currently logged in members first name or surname contain XSS, this prints the raw HTML out, because Member->getName() just returns the raw FirstName + Surname as a string, which is injected directly.

  Credit to Matt Peel for reporting.

• SS-2016-012: Missing ACL on reports

  Severity:

  Low (?)

  Identifier:

  ss-2016-012

  Versions Affected:

  3.1.19, 3.2.4, 3.3.2. 3.4.0

  Versions Fixed:

  3.1.20, 3.2.5, 3.3.3. 3.4.1

  Release Date:

  2016-08-15

  The SS_Report, and the reports CMS section only checks canView() when listing the reports that can be viewed by the current user.

  It does not (and should) perform canView checks when the report is actually viewed, so if you know the URL to a report and can otherwise access the Reports section of the CMS, you can view any report.

  Credit to Matt Peel for reporting.

• SS-2016-011: ChangePasswordForm doesn't check Member::canLogIn()

  Severity:

  Low (?)

  Identifier:

  ss-2016-011

  Versions Affected:

  3.1.19, 3.2.4, 3.3.2. 3.4.0

  Versions Fixed:

  3.1.20, 3.2.5, 3.3.3. 3.4.1

  Release Date:

  2016-08-15

  After performing a password reset, ChangePasswordForm::doChangePassword() logs in the user without checking Member::canLogIn(). This presents an issue for sites that are using the extension point in that method to deny access to users (for example members that have not been “approved”, or members that have had their access revoked temporarily). It looks like Member::canLogIn() was originally designed to only be used for checking whether the user is locked out (due to too many incorrect login attempts) but has been opened up to other uses.

  Credit to Loz Calver

• SS-2016-008: Password encryption salt expiry

  Severity:

  Low (?)

  Identifier:

  ss-2016-008

  Versions Affected:

  3.1.19, 3.2.4, 3.3.2. 3.4.0

  Versions Fixed:

  3.1.20, 3.2.5, 3.3.3. 3.4.1

  Release Date:

  2016-08-15

  When a user changes their password, the internal salt used for hashing their password is not updated.

  Although this is not considered a security vulnerability, this behaviour has been improved to ensure the salt is reset on change of password.

  Credit to Jono Menz.

• SS-2016-007: VersionedRequestFilter vulnerability

  Severity:

  Low (?)

  Identifier:

  ss-2016-007

  Versions Affected:

  3.3.0 to 3.3.2. 3.4.0

  Versions Fixed:

  3.3.3. 3.4.1

  Release Date:

  2016-08-15

  A cross-site scripting vulnerability in VersionedRequestFilter has been found.

  If an incoming user request should not be able to access the requested stage, an error message is created for display on the CMS login page that they are redirected to. In this error message, the URL of the requested page is interpolated into the error message without being escaped; hence, arbitrary HTML can be injected into the CMS login page.

  Credit to Matthew Daley for reporting this issue.

• SS-2016-006: Missing CSRF protection in login form

  Severity:

  Low (?)

  Identifier:

  SS-2016-006

  Versions Affected:

  3.1.18, 3.2.3, 3.3.1

  Versions Fixed:

  3.1.19, 3.2.4, 3.3.2

  Release Date:

  2016-05-11

  LoginForm calls disableSecurityToken(), which causes a "shared host domain" vulnerability: http://stackoverflow.com/a/15350123.

  Credit: Anthony Thorpe

• SS-2016-005: Brute force bypass on default admin

  Severity:

  High (?)

  Identifier:

  SS-2016-005

  Versions Affected:

  3.1.18, 3.2.3, 3.3.1

  Versions Fixed:

  3.1.19, 3.2.4, 3.3.2

  Release Date:

  2016-05-11

  Default Administrator accounts were not subject to the same brute force protection afforded to other Member accounts. Failed login counts were not logged for default admins resulting in unlimited attempts on the default admin username and password.

  Credit: Will Rossiter 

• SS-2016-004: XSS in CMS Edit Page

  Severity:

  Medium (?)

  Identifier:

  SS-2016-004

  Versions Affected:

  3.1.18, 3.2.3, 3.3.1

  Versions Fixed:

  3.1.19, 3.2.4, 3.3.2

  Release Date:

  2016-05-11

  Due to a lack of parameter sanitisation a carefully crafted URL could be used to inject arbitrary HTML into the CMS Edit page.

  An attacker could create a URL and share it with a site administrator to perform an attack.

  Credit: Eric Flokstra.

• SS-2016-001: XSS in CMSController BackURL

  Severity:

  High (?)

  Identifier:

  SS-2016-001

  Versions Affected:

  3.1.18, 3.2.3, 3.3.1

  Versions Fixed:

  3.1.19, 3.2.4, 3.3.2

  Release Date:

  2016-05-11

  A XSS risk exists in the returnURL parameter passed to CMSSecurity/success. An unvalidated url could cause the user to redirect to an unverified third party url outside of the site.

  Credit: David Júlio for reporting.

• SS-2015-029: CSRF vulnerability in savetreenodes

  Severity:

  Low (?)

  Identifier:

  SS-2015-029

  Versions Affected:

  3.1.18, 3.2.3, 3.3.1

  Versions Fixed:

  3.1.19, 3.2.4, 3.3.2

  Release Date:

  2016-05-11

  savetreenode action does not have sufficient CSRF protection, meaning that in some cases users with CMS access can be tricked into posting unspecified data into the CMS from external websites.

  The resolution for this issue is to ensure that a security token is sent with the request and validated on the server side.

  Credit: Alain J Homewood - PWC

• SS-2016-003: Hostname, IP and Protocol Spoofing through HTTP Headers

  Severity:

  Low (?)

  Identifier:

  SS-2016-003

  Versions Affected:

  3.1.16, 3.2.1, 3.3.0-rc2 and below

  Versions Fixed:

  3.1.17, 3.2.2, 3.3.0

  Release Date:

  2016-02-24

  In it's default configuration, SilverStripe trusts all originating IPs to include HTTP headers for Hostname, IP and Protocol. This enables reverse proxies to forward requests while still retaining the original request information. Trusted IPs can be limited via the SS_TRUSTED_PROXY_IPS constant. Even with this restriction in place, SilverStripe trusts a variety of HTTP headers due to different proxy notations (e.g. X-Forwarded-For vs. Client-IP). Unless a proxy explicitly unsets invalid HTTP headers from connecting clients, this can lead to spoofing requests being passed through trusted proxies.

  The impact of spoofed headers can include Director::forceSSL() not being enforced, SS_HTTPRequest->getIP() returning a wrong IP (disabling any IP restrictions), and spoofed hostnames circumventing any hostname-specific restrictions enforced in SilverStripe Controllers.

  Regardless on running a reverse proxy in your hosting infrastructure, please follow the instructions on Secure Coding: Request hostname forgery in order to opt-in to these protections. If your website is not behind a reverse proxy, you might already be protected if using Apache with mod_env enabled, and you have the following line in your .htaccess file: SetEnv BlockUntrustedIPs true.

  CVSS Score: 1.4

  Credit to Patrick Nelson (https://catchyour.com/) and Ingo Schommer for reporting.

• SS-2016-002: CSRF vulnerability in GridFieldAddExistingAutocompleter

  Severity:

  High (?)

  Identifier:

  SS-2016-002

  Versions Affected:

  3.1.16, 3.2.1, 3.3.0-rc2 and below

  Versions Fixed:

  3.1.17, 3.2.2, 3.3.0

  Release Date:

  2016-02-24

  GridField does not have sufficient CSRF protection, meaning that in some cases users with CMS access can be tricked into posting unspecified data into the CMS from external websites. Amongst other default CMS interfaces, GridField is used for management of groups, users and permissions in the CMS.

  The resolution for this issue is to ensure that all gridFieldAlterAction submissions are checked for the SecurityID token during submission.

  CVSS Score: 3.6

  Credit to Ashraf Alharbi from Security-Assessment.com for reporting.

• SS-2015-028: Missing security check on dev/build/defaults

  Severity:

  Medium (?)

  Identifier:

  SS-2015-028

  Versions Affected:

  3.1.16, 3.2.1, 3.3.0-rc2 and below

  Versions Fixed:

  3.1.17, 3.2.2, 3.3.0

  Release Date:

  2016-02-24

  The buildDefaults method on DevelopmentAdmin is missing a permission check.

  In live mode, if you access /dev/build, you are requested to login first. However, if you access /dev/build/defaults, then the action is performed without any login check. This should be protected in the same way that /dev/build is.
  The buildDefaults view is requireDefaultRecords() on each DataObject class, and hence has the potential to modify database state. It also lists all modified tables, allowing attackers more insight into which modules are used, and how the database tables are structured.

  CVSS Score: 3.5

  Credit to Matt Peel and Robby Ahn for reporting

• Prev
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• Next