Kia ora,

An important security release 1.2.1 of the CWP Basic Recipe has been released on the 10 March 2016.

This release includes several security fixes to CMS, Framework, and some other modules.

When do you need to perform this upgrade?

All Agencies using Recipe 1.2.0 or below must upgrade prior to 10 June 2016 to either Recipe 1.2.1 or 1.3.0. All sites using prior versions of the CWP Basic Recipe (1.2.0 and below) should be considered vulnerable. Please organise this with your developers as soon as possible.

Note that you will need to upgrade to Recipe 1.2.1 even if you have upgraded to Recipe 1.2.0 just recently. However, SilverStripe expect such an upgrade to be smooth.

In case you are already planning to upgrade to 1.3.0 you can disregard this message.

Information to help manage upgrades is here.

If you have any questions about the upgrade process, then please email the CWP Product Manager.

What is in Recipe 1.2.1?

This recipe version is a security release for 1.2.0, and only contains necessary upgrades in order to resolve known security vulnerabilities and bugs.

This includes an upgrade of the SilverStripe CMS and Framework to version 3.2.3, which includes important improvements in security over 3.2.1. Translatable has also been updated to 1.2.1.

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-2016-003]: 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.
  
• [SS-2015-028]: 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.
  
• [SS-2016-002]: 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.

Technical Upgrade Guide

A description for technical staff on how to carry out an upgrade is found here.

Kind regards,
CWP Team