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

• SS-2015-017: Forum Module CSRF Vulnerability

  Severity:

  Critical (?)

  Identifier:

  ss-2015-017

  Versions Affected:

  0.6.1 and below, 0.7.0 to 0.7.3

  Versions Fixed:

  0.6.2, 0.7.4, 0.8.0

  Release Date:

  2015-08-10

  A number of form actions in the Forum module are directly accessible. A malicious user (e.g. spammer) can use GET requests to create Members and post to forums, bypassing CSRF and anti-spam measures.

  Additionally, a forum moderator could be tricked into clicking a specially crafted URL, resulting in a topic being moved.

  Thanks to Michael Strong for discovering.

  Common Vulnerability Scoring System (VCSS) Information

• SS-2015-014: Vulnerability on "isDev", "isTest" and "flush" $_GET validation

  Severity:

  High (?)

  Identifier:

  SS-2015-014

  Versions Affected:

  3.0.13 and below, 3.1.0 to 3.1.13-rc1

  Versions Fixed:

  3.0.14, 3.1.13

  Release Date:

  2015-05-28

  When a secure token parameter is provided to a SilverStripe site (such as isDev or flush) an empty token parameter can be provided in order to bypass normal authentication parameters.

  For instance, http://www.mysite.com/?isDev=1&isDevtoken will force a site to dev mode. Alternatively, "flush" could also be used in succession to cause excessive load on a victim site and risk denial of service.

  The fix in this case is to ensure that empty tokens fail the validation check.

  Download Fix for 3.0 or Download Fix for 3.1

  Common Vulnerability Scoring System (CVSS) Information

  Credit to Patrick Nelson (https://catchyour.com/) for reporting this issue.

• SS-2015-013: X-Forwarded-Host request hostname injection

  Severity:

  High (?)

  Identifier:

  SS-2015-013

  Versions Affected:

  3.1.13-rc1 and below

  Versions Fixed:

  3.1.13

  Release Date:

  2015-05-28

  A potential hostname injection vulnerability has been found which could allow attackers to alter url resolution.

  If a request contains the X-Forwarded-Host HTTP header a website would then use its value in place of the actual HTTP hostname. In cases where caching is enabled, this could allow an attacker to potentially embed a remote url as the base_url for any site. This would then cause other visitors to the site to be redirected unknowingly.

  This header is necessary for servers running behind a reverse proxy (such as nginx). Such servers are likely not vulnerable to this risk.

  A fix has been merged into the default installer, although existing projects which do not run behind a reverse proxy should update their htaccess as below:

  <IfModule mod_headers.c>
      # Remove X-Forwarded-Host header sent as a part of any request from the web
      RequestHeader unset X-Forwarded-Host
  </IfModule>

  Common Vulnerability Scoring System (CVSS) Information

  Thanks to Dariusz Półtorak for identifying this issue.

• SS-2015-012: External redirection risk in Security?ReturnURL

  Severity:

  Medium (?)

  Identifier:

  SS-2015-012

  Versions Affected:

  3.0.13 and below, 3.1.0 to 3.1.13-rc1

  Versions Fixed:

  3.0.14, 3.1.13

  Release Date:

  2015-05-28

  A vulnerability has been found in the SilverStripe framework where a login url can be potentially redirected to an external site.

  For example, the url http://www.my-silverstripe-site.com/Security/login?BackURL=/\attacker-site.com will redirect successful logins to the page http://attacker-site.com. If that website were set up to look identical to the first with "login failed" then the user will likely just enter their user/pass again.

  Common Vulnerability Scoring System (CVSS) Information

  Credit to Matt Lang for reporting this issue.

• SS-2015-011: Potential SQL Injection Vulnerability

  Severity:

  Low (?)

  Identifier:

  SS-2015-011

  Versions Affected:

  3.0.13 and below, 3.1.0 to 3.1.13-rc1

  Versions Fixed:

  3.0.14, 3.1.13

  Release Date:

  2015-05-28

  A potential SQL injection vulnerability exists in SQLQuery when used in conjunction with the default FulltextSearch functionality.

  When a search query containing the term " as " is performed, SQLQuery will misunderstand the SQL generated by MySQLDatabase and attempt to rewrite the query in a way that generates malformed queries. This is due to support for legacy behaviour being incorrectly implemented. However, valid SQL cannot be generated using this exploit.

  A fix has been applied to correct the legacy support.

  Common Vulnerability Scoring System (CVSS) information

  Thanks to Ed Chipman for reporting this vulnerability.

• SS-2015-010: XSS in Director::force_redirect()

  Severity:

  Low (?)

  Identifier:

  SS-2015-010

  Versions Affected:

  3.1.0 to 3.1.11

  Versions Fixed:

  3.1.12

  Release Date:

  2015-03-20

  A low level XSS vulnerability has been found in the Framework affecting http redirection via the Director::force_redirect method.

  Attempts to redirect to a url may generate HTML which is not safely escaped, and may pose a risk of XSS in some environments.

  This vulnerability is marked low as it is difficult to exploit, as any injected HTML will only be returned from the server if the Location HTTP header is also sent, meaning that any user browsing the site would not be exposed to the body of the response before their browser redirects them.

• SS-2015-009: XSS In rewritten hash links

  Severity:

  High (?)

  Identifier:

  SS-2015-009

  Versions Affected:

  3.0.12 and below, 3.1.0 - 3.1.11

  Versions Fixed:

  3.0.13, 3.1.12

  Release Date:

  2015-03-20

  A high level XSS vulnerability has been discovered in the SilverStripe framework which causes links containing hash anchors (E.g. href="#anchor") to be rewritten in an unsafe way.

  The rewriteHashlinks option on SSViewer will rewrite these to contain the current url, although without adequate escaping, meaning that HTML could be injected via injecting unsafe values to any page via the querystring.

  Due to the nature of this issue it is likely that a large number of SilverStripe sites are affected.

  Special credit to Dariusz Półtorak for reporting the issue and providing us with lots of helpful information, as well as the "Happy Endians" team, part of CP DDB.

• SS-2014-017: XML Quadratic Blowup Attack

  Severity:

  Low (?)

  Identifier:

  SS-2014-017

  Versions Affected:

  3.1.11 and below

  Versions Fixed:

  3.1.12

  Release Date:

  2015-03-20

  A low level vulnerability has been found in the SilverStripe framework, where the Quadratic Blowup Attack could potentially be exploited to affect the performance of a site.

  See http://mashable.com/2014/08/06/wordpress-xml-blowup-dos/ for a writeup.

  Thanks to Jamie Totten.

• SS-2014-015: IE requests not properly behaving with rewritehashlinks

  Severity:

  Medium (?)

  Identifier:

  SS-2014-015

  Versions Affected:

  3.0.12 and below, 3.1.0 - 3.1.11

  Versions Fixed:

  3.0.13, 3.1.12

  Release Date:

  2015-03-20

  Non IE browsers don’t appear to be affected, but I haven’t tested a wide range of browsers to be sure 

  Requests that come through from IE do NOT appear to encode all entities in the URL string, meaning they are inserted into output content directly by SSViewer::process() when rewriting hashlinks, as it directly outputs $_SERVER[‘REQUEST_URI’]

  Example IE8 request
  127.0.0.1 - - [18/Jun/2014:14:13:42 +1000] “GET /site/cars/brands/toyota?one=1\”onmouseover=\”alert(‘things’);\” HTTP/1.1” 200

  Example FF request
  127.0.0.1 - - [18/Jun/2014:14:14:22 +1000] “GET /site/cars/brands/toyota?one=1\%22onmouseover=\%22alert(%27things%27);\%22 HTTP/1.1” 200

  This causes any hash anchor to have the JS code inserted into the page as-is.

   

  Credit to Marcus Nyeholt for identifying this issue

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