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-2014-007: Confidentiality breach can occur between draft and live modes

  Severity:

  Medium (?)

  Identifier:

  SS-2014-007

  Versions Affected:

  3.1.3, 3.0.9, and all versions before

  Versions Fixed:

  3.1.4, 3.0.10

  Release Date:

  2014-04-01

  In cases were partial caching is used in templates, it's possible for content viewed in one versioned mode (such as stage) to be cached and presented later to other uses in live. This issue also extends to content that may be customised for individual users, such as login status. This may lead to incorrect data being presented within partially cached data, or may leak confidential or unpublished data that should not be viewable.

  In order to resolve this a global caching key is applied to all partial caches by default. This is a string which is automatically added to the cache identifier for all partial caches. By default this is set to '$CurrentReadingMode, $CurrentUser.ID', but can be customised by setting the config value for 'SSViewer.global_key', and can contain any template syntax.

  This fix will likely require some adjustment for website which either allow for user logins, as the default global cache key may not be appropriate in all situations.

  For instance, if your partial caching already handles user login status where necessary, this key can be simplified to only segment by reading mode. In your config.yml you should change this key as below:

  SSViewer:
    global_key: '$CurrentReadingMode'

  To upgrade download or update with composer

• SS-2014-006: XSS in returnURL redirection

  Severity:

  Low (?)

  Identifier:

  SS-2014-006

  Versions Affected:

  3.0.9, 3.1.3, and all versions before

  Versions Fixed:

  3.0.10, 3.1.4

  Release Date:

  2014-04-01

  If an attacker can set the URL passed to Controller->redirect() and output is sent to the browser before the redirect can occur, the URL may be outputted directly to the browser.

  This can potentially be exploited through dev/build, i.e. http://site.com/dev/build?returnURL=/"><h1>Hacked!</h1><!--

  If the response is buffered enough that output hasn’t been sent to the browser yet this particular attack vector isn’t available on a stock install, but others may be and it may still be available in customised installs.

  The fix is to escape the URL before displaying it to the user.

  Download Patch for 3.1 | Download Patch for 3.0

  Thanks to Simon Welsh for reporting and providing a patch.

• SS-2014-005: Arbitrary class creation in CMS backend

  Severity:

  Low (?)

  Identifier:

  SS-2014-005

  Versions Affected:

  3.0.9, 3.1.3, and all previous versions

  Versions Fixed:

  3.0.10, 3.1.4

  Release Date:

  2014-04-01

  By changing the PageType value passed to CMSPageAddController, a user is able to create any arbitrary class. If this class is a DataObject, it will be written to the database. This allows a user to create classes that they should not be able to.

  The is fixed by changing CMSMain->getNewItem() to only create classes that are subclasses of the tree_class (SiteTree in most cases).

  At this stage, there is no known way to use this for arbitary code execution, or arbitary database access, thus the issue is rated low severity.

  Download Patch for 3.1 | Download Patch for 3.0

  Thanks to Simon Welsh for reporting and submitting a patch.

• SS-2014-004: SQL injection in SiteTree with custom URLSegmentFilter rules

  Severity:

  Low (?)

  Identifier:

  SS-2014-004

  Versions Affected:

  3.1.3, 3.0.9, and all versions before

  Versions Fixed:

  3.1.4, 3.0.10

  Release Date:

  2014-04-01

  When a developer removes the default URLSegmentFilter rule, the CMS backend is vulnerable to SQL Injection, as apostrophes are not removed.

  The change will make sure the URL is always escaped, regardless of the URL filters.

  Download Patch for 3.1 | Download Patch for 3.0

  Thanks to Simon Welsh for reporting and submitting a patch.

• SS-2014-008: Lack of CSRF tokens in Forum module

  Severity:

  Medium (?)

  Identifier:

  SS-2014-008

  Versions Affected:

  0.4, 0.5, master

  Versions Fixed:

  0.4.1, 0.5.1, master

  Release Date:

  2014-03-17

  The forum module was lacking CSRF tokens on all non form based actions, such as deletepost and markasspam, which would allow an attacker to execute these actions by getting an authenticated user to visit specifically crafted links.

  A patch has been made which will add CSRF tokens to all front-end accessible actions, except for Unsubscribe.
  Because unsubscribe is used in emails, it requires a different solution to prevent this kind of attack. For now, the usability lost by introducing CSRF tokens outweighs the potential for misuse by malicious forum users. A permanant solution is currently being investigated, but will not be counted as a security release once it is complete.

  Thanks to Vincze Márton for reporting.

• SS-2014-003: ExtraMeta allows JavaScript for malicious CMS authors

  Severity:

  Low (?)

  Identifier:

  SS-2014-003

  Versions Affected:

  3.0.8, 3.1.2 and all earlier versions

  Versions Fixed:

  3.1.3

  Release Date:

  2014-02-19

  The CMS allows specifying custom HTML to be placed in the <head> section of a specific page (through the SiteTree.ExtraMeta property). The main intention is to add <meta> tags further describing the content present. Since the accepted format is HTML, any content can be inserted by CMS authors, including <script> tags containing inline JavaScript or external sources. In order to exploit this issue, you need to have CMS access in the first place. Other potential weaknesses like transient cross-site scripting (XSS) through malicious links can abuse the CMS author login status, and transform attacks a persistent XSS issue.

  While there is no known vector to exploit this without a valid CMS login, the core team feels its safest to whitelist the tags allowed in the ExtraMeta property, defaulting to <link> and <meta> only. This means existing projects with page-specific <script> tags will need to have these tags moved into SilverStripe templates. Alternatively, you can add a new HTMLText $db property in your Page class definition (suggested name: $HeaderScripts).

  This whitelist will not apply to existing data in the SiteTree.ExtraMeta column on existing pages. In order to ensure no exploit has already been persisted, and check if you need to move <script> tags to templates, we suggest you search this column in your project database:
  SELECT * FROM "SiteTree" WHERE "SiteTree"."ExtraMeta" LIKE '%<script%'
  SELECT * FROM "SiteTree_Live" WHERE "SiteTree"."ExtraMeta" LIKE '%<script%'

  Download CMS patch for 3.1 | Download framework patch for 3.1

  Thanks to Daniel Hensby for reporting.

• SS-2014-002: XSS in third party library (SWFUpload)

  Severity:

  Medium (?)

  Identifier:

  SS-2014-002

  Versions Affected:

  3.0.8, 3.1.2 and all earlier versions

  Versions Fixed:

  3.0.9,3.1.3

  Release Date:

  2014-02-19

  A third party JavaScript library (SWFUpload) is susceptible to cross-site scripting through its SWF interface (details). This library has been removed from core, mitigating this attack vector.

  Download patch for 3.1 | Download patch for 3.0

  Thanks to Marc Wickenden for reporting.

• SS-2014-001: Require ADMIN for ?flush=1&isDev=1

  Severity:

  Low (?)

  Identifier:

  SS-2014-001

  Versions Affected:

  3.0.8, 3.1.2 and all earlier versions

  Versions Fixed:

  3.0.9,3.1.3

  Release Date:

  2014-02-19

  Flushing the various manifests (class, template, config) is performed through a GET parameter (flush=1). Since this action requires more server resources than normal requests, it can facilitate denial-of-service attacks. This action has been secured as part of SS-2013-001, but an edge case was missed when also using the isDev=1 GET parameter. It allows a live site to be placed in development mode for logged-in administrators. When used in combination with flush=1, the check for logged-in administrators was bypassed, which is now fixed.

  Download patch for 3.1 | Download patch for 3.0

  Thanks to Stephen Shkardoon and Simon Welsh for reporting.

• SS-2013-009: XSS in CMS "Pages" section

  Severity:

  Low (?)

  Identifier:

  SS-2013-009

  Versions Affected:

  3.0,3.1

  Versions Fixed:

  3.0.7,3.1.0-rc3

  Release Date:

  2013-09-24

  The "Insert Link" dropdown and "Dependent Pages" list in the "Pages" CMS section are vulnerable to persistent cross-site scripting, through the SiteTree.Title attribute. This form of attack requires a CMS login by a malicious third party, and can lead to executing authenticated requests on behalf of the CMS user victim. 

• SS-2013-008: XSS in form validation errors

  Severity:

  Low (?)

  Identifier:

  SS-2013-008

  Versions Affected:

  3.0.6,3.1.0

  Versions Fixed:

  3.0.7,3.1.0-rc3

  Release Date:

  2013-09-24

  The CMS allows for user feedback through custom messages generated by form or form field validation. If these messages incorporate user-provided data such as quoting a wrongly formatted value, it can lead to cross-site scripting. Usually validation messages prevent form saving, so the malicious input is usually not persisted, nor accessible for other users. But since Form->sessionMessage() can also be used to pass success messages to the user, this can lead to persisted malicious input in rare cases where stored data is used to compose this message.

  Form and form field messages are assumed to be plain text, and escaped by default. 

  Reported by Vulnerability Laboratory Evolution

• SS-2013-007: XSS in CMS "Security" section

  Severity:

  Low (?)

  Identifier:

  SS-2013-007

  Versions Affected:

  3.1.0

  Versions Fixed:

  3.1.0-rc3

  Release Date:

  2013-09-24

  Certain fields in the "Groups" and "Roles" listings of the "Security" section are vulnerable to persistent cross-site scripting. This form of attack requires a CMS login by a malicious third party, and can lead to executing authenticated requests on behalf of the CMS user victim.

  Reported by Vulnerability Laboratory Evolution

• SS-2013-006: Information disclosure in Versioned.php

  Severity:

  Low (?)

  Identifier:

  SS-2013-006

  Versions Affected:

  3.0

  Versions Fixed:

  3.0.6

  Release Date:

  2013-09-12

  Malicious website visitors can inspect older and newer versions of website content without requiring CMS access, through special URL parameters usually reserved for CMS users. This includes unpublished content.

  This has been fixed by more specific permission checks in ContentController.php

• SS-2013-005: Privilege escalation with APPLY_ROLES

  Severity:

  Low (?)

  Identifier:

  SS-2013-005

  Versions Affected:

  2.4,3.0,3.1

  Versions Fixed:

  2.4.11,3.0.6,3.1.0

  Release Date:

  2013-09-12

  CMS users with access to the "Security" admin interface can increase their privileges to ADMIN if they currently just hold the permission "Apply roles to groups" (APPLY_ROLES). They can exploit their access either by assigning privileged permissions to a group they already belong to, or by creating a new role with more privileged permissions.

  Only a small number of advanced installations should have this "sub-admin" role set up which makes them vulnerable to this issue. Note that APPLY_ROLES still allows users with access to the "Security" interface to assign themselves to non-privileged permissions such as editing CMS content or CMS settings. This is by design. It is also advised to use the built-in "Only admins can apply" flag on roles which are deemed privileged, which already prevents "sub-admins" from assigning this role to a group they belong to. 
  

  This has been fixed by additional validation on the PermissionRoleCode model.

• SS-2013-004: Privilege escalation through Group and Member CSV upload

  Severity:

  Low (?)

  Identifier:

  SS-2013-004

  Versions Affected:

  2.4,3.0,3.1

  Versions Fixed:

  2.4.12,3.0.6,3.1.0

  Release Date:

  2013-09-12

  The "Security" admin interface allows import of member and group records from CSV data. CMS users with CMS_ACCESS_SecurityAdmin permission but without ADMIN permissions can increase their CMS privileges through this mechanism. Only a small number of advanced installations should have separate "sub-admin" groups set up which makes them vulnerable to this issue.

  Access to this functionality has been limited to users with the ADMIN permission. If you're using the underlying GroupCsvBulkLoader or MemberCsvBulkLoader classes directly, please ensure they're appropriately secured.

• SS-2013-003: Privilege escalation through Group hierarchy setting

  Severity:

  Low (?)

  Identifier:

  SS-2013-003

  Versions Affected:

  2.4,3.0,3.1

  Versions Fixed:

  2.4.12,3.0.6,3.1.0

  Release Date:

  2013-09-12

  CMS users with access to the "Security" admin interface, but without ADMIN permissions, are able to increase their privileges. Since groups inherit permissions from parent groups, any changes to a group that a malicious user belongs to can inherit further privileged permissions. Note: Only a small number of advanced installations should have separate "sub-admin" groups set up which makes them vulnerable to this issue.

  This was fixed by limiting group hierarchy changes to those without a set of privileged permissions (CMS_ACCESS_SecurityAdmin, EDIT_PERMISSIONS, APPLY_ROLES, ADMIN), unless the currently logged-in user has ADMIN permissions already.

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