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

• SS-2015-022: XML escape RSSFeed $link parameter

  Severity:

  Low (?)

  Identifier:

  SS-2015-022

  Versions Affected:

  3.1.15 and below, 3.2.0

  Versions Fixed:

  3.1.16, 3.2.1

  Release Date:

  2015-11-16

  When RSSLink is created it is given a URL which is rendered via $Link in a template, which is not escaped properly. 
  This was resolved by ensuring that $Link is cast to Varchar, which is XML encoded by default in any template.

  Common Vulnerability Scoring System (VCSS) Information

• SS-2015-021: Hash rewrite URL filtering

  Severity:

  Medium (?)

  Identifier:

  SS-2015-021

  Versions Affected:

  3.1.15 and below, 3.2.0

  Versions Fixed:

  3.1.16, 3.2.1

  Release Date:

  2015-11-16

  When SSViewer rewrites has links, it takes the whole URL after the base and prepends it to the hash. So for http://example.com/foo, links like "#" become "/foo#". This prevents them being interpreted as relative to the base tag (i.e. as "http://example.com/#")

  However this URL isn't well filtered, so a URL like http://example.com//evil.com will have it's hash links be rewritten to be "//evil.com#"

  This fix has been resolved by pre-filtering $_SERVER['REQUEST_URI'] to clean leading double-slashes which would otherwise denote such urls as protocol-relative links.

  Common Vulnerability Scoring System (CVSS) Information

• SS-2015-020: Privilege Escalation Risk in Security Admin

  Severity:

  Low (?)

  Identifier:

  SS-2015-020

  Versions Affected:

  3.1.14-rc1

  Versions Fixed:

  3.1.14 stable

  Release Date:

  2015-09-15

  A member with the permission EDIT_PERMISSIONS is able to re-assign themselves (or another member) to ADMIN level.

  Code to protect against this used to be in the TreeMultiselectField, but has since been replaced with the ListboxField. The actual check this invoked was in Member::onChangeGroups.

  Thanks to Florian Thoma for reporting.

• SS-2015-016: XSS in install.php

  Severity:

  Low (?)

  Identifier:

  SS-2015-016

  Versions Affected:

  3.1.14-rc1 and below

  Versions Fixed:

  3.1.14 stable

  Release Date:

  2015-09-15

  During installation, certain parameters (admin_username and admin_password) are not escaped in the setup form.

  This issue is resolved in 3.1.14 stable, although existing users are advised to remove this file prior to deploying to a production server.

• SS-2015-015: XSS in dev/build returnURL Parameter

  Severity:

  Low (?)

  Identifier:

  ss-2015-015

  Versions Affected:

  3.1.14-rc1 and below

  Versions Fixed:

  3.1.14 stable

  Release Date:

  2015-09-15

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

  This issue is resolved in framework 3.1.14 stable release.

• SS-2015-018: File upload exposure on UserForms module

  Severity:

  Medium (?)

  Identifier:

  SS-2015-018

  Versions Affected:

  Userforms 3.0.0 beta 1 and below

  Versions Fixed:

  Userforms 3.0.0 final

  Release Date:

  2015-08-31

  The userforms module allows CMS administrators to create public facing forms with file upload abilities. These files are uploaded into a predictable public path on the website, unless configured otherwise by the CMS administrator setting up the form. While the name of the uploaded file itself is not predictable, certain actions taken by CMS authors could expose it. For example, submission notification emails contain a link to the file without authorisation checks.
  
  In 3.0.0 this field is disabled by default, but re-enabled upon installation of the secure assets module. When this is installed, the field can once again be used within a form, and will automatically lock this folder to a secure list of users, which can then be configured further by an administrator.

  Existing file upload fields will not be disabled, but will require re-enabling via config or installation of secure assets to become editable again.

  If any upload field points or is pointed to a folder that is not secured, and the secure assets module is present, then that folder will have the secure permissions applied automatically.

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