Security release 1.2.0 of the CWP Basic Recipe has been released on the 9th December 2015.
This release includes several security fixes to cms, framework, and some other modules.
When do you need to perform this upgrade?
Agencies must upgrade prior to 1st March 2016. All sites using prior versions of the CWP Basic Recipe (1.1.2 and below) should be considered vulnerable. Please organise this with your developers as soon as possible. If an agency has not upgraded by that date, SilverStripe is obliged to perform the upgrade under the terms of the contract. This is a last resort as it will incur cost and creates a risk of functionality breaking.
Information to help manage upgrades is here.
What is in release 1.2.0?
This release includes an upgrade of the SilverStripe CMS and Framework to version 3.2.1, which includes huge improvements in security and database performance over 3.1.
This release will also include the following new modules.
- Content-Review: https://github.com/silverstripe/silverstripe-contentreview. Allows content editors to receive periodic notifications on pages to remind them to do regular reviews. This module is installed and available by default.
- Site-wide content report: https://github.com/silverstripe/silverstripe-sitewidecontent-report. Provides an overview of pages and files, grouped by subsite. This module is installed and available by default.
- Realme Authentication module: https://github.com/silverstripe/silverstripe-realme Provides CWP site authentication via https://www.realme.govt.nz/. This module must be installed separately, and requires server side configuration before it may be used. See the CWP realme documentation for more information.
The full release notes are available on the releases page here.
Details of security issues in this release
This release includes fixes for the following issues:
- [SS-2015-021]: When SSViewer rewrites has links, it takes the whole URL after the base and prepends it to the hash. 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.
- [SS-2015-022]: 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.
- [SS-2015-023]: Advanced workflow member field exposure. 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.
- [SS-2015-024]: Queued jobs serialised data exposure. 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.
- [SS-2015-025]: 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.
- [SS-2015-026]: A high severity 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.
- [SS-2015-027]: When embedding files in the HTML editor, "Add from URL" doesn't clearly sanitise URL server side. 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.
Technical Upgrade Guide
A description for technical staff on how to carry out an upgrade is found here.