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-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

• SS-2015-019: Leaky draft stage risk

  Severity:

  Low (?)

  Identifier:

  SS-2015-019

  Versions Affected:

  3.2 and below

  Versions Fixed:

  3.3.0-beta1

  Release Date:

  2015-12-23

  In some cases, user code which applies Versioned extension to DataObjects may expose non-public content, unless an appropriate canView is implemented which checks access for the current stage.

  This is a risk in cases that the site is put into staging mode by an unauthenticated user.

  In 3.3.0 versioned dataobjects will now automatically have a default security model which denies draft access to public users, and directly blocks access to the stage mode via the querystring.

  This is accepted as not a security bug but rather a risk to mitigate common errors in user code which fail to address appropriate permission checks. Please read the security documentation on versioning for more information on how site developers can secure their code.

• SS-2015-024: Queued jobs serialised data exposure

  Severity:

  Low (?)

  Identifier:

  SS-2015-024

  Versions Affected:

  2.8.1 and below

  Versions Fixed:

  2.8.3

  Release Date:

  2015-11-23

  SavedJobData and SavedJobMessages contain php serialised data. There's no point showing these to a CMS Admin as they're not human readable. Worse, it might be insecure, as a malicious CMS Admin might be able to craft a payload thats dangerous to unserialise.

  This issue has been resolved by hiding this content, even from administrators.

  Common Vulnerability Scoring System (CVSS) Information

• SS-2015-023: Advanced workflow member field exposure

  Severity:

  Low (?)

  Identifier:

  SS-2015-023

  Versions Affected:

  3.2.1 and below

  Versions Fixed:

  3.2.3

  Release Date:

  2015-11-23

  By default, the CMS Admin editable template for the NotifyUsers action has access to a large number of fields, including (for instance) Member#Password. This would allow a malicious CMS Admin to extract other admin passwords by adding a template emailing these fields to themselves when other admins trigger the workflow.

  A new configuration option `NotifyUsersWorkflowAction.whitelist_template_variables` has been added. When this option is set to true via the Config API then only member fields specified via Member.summary_fields may be accessed.

  Common Vulnerability Scoring System (CVSS) Information

• SS-2015-027: HtmlEditor embed url sanitisation

  Severity:

  Low (?)

  Identifier:

  ss-2015-027

  Versions Affected:

  3.2.0 and below

  Versions Fixed:

  3.2.1

  Release Date:

  2015-11-16

  "Add from URL" doesn't clearly sanitise URL server side

  HtmlEditorField_Toolbar has an action HtmlEditorField_Toolbar#viewfile, which gets called by the CMS when adding a media "from a URL" (i.e. via oembed).

  This action gets the URL to add in the GET parameter FileURL. However it doesn't do any URL sanitising server side. The current logic will pass this through to Oembed, which will probably reject most dangerous URLs, but it's possible future changes would break this.

  Common Vulnerability Scoring System (CVSS) Information

• SS-2015-026: Form field validation message XSS vulnerability

  Severity:

  High (?)

  Identifier:

  ss-2015-026

  Versions Affected:

  3.1.15 and below, 3.2.0

  Versions Fixed:

  3.1.16, 3.2.1

  Release Date:

  2015-11-16

  A high level XSS risk has been identified in the encoding of validation messages in certain FormField classes.

  Certain fields such as the NumericField and DropdownField have been identified, but any form field which presents any invalid content as a part of its validation response will be at risk.

  Common Vulnerability Scoring System (CVSS) Information

  Credit to "Arjun Basnet from Cyber Security Works Pvt.Ltd (http://cybersecurityworks.com/)"

• SS-2015-025: Request class name exposure on error

  Severity:

  Low (?)

  Identifier:

  SS-2015-025

  Versions Affected:

  3.1.15 and below, 3.2.0

  Versions Fixed:

  3.1.16, 3.2.1

  Release Date:

  2015-11-16

  RequestHandler would include the class name in the unstyled 403 & 404 responses. This is a slight information leak that could be used by an attacker.

  This issue has been resolved by suppressing these errors on live.

  Common Vulnerability Scoring System (CVSS) Information

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