Kia ora,

Security release 1.3.0 of the CWP Basic Recipe has been released on the 29th February 2016.

This release includes some medium level security fixes to cms and framework.

When do you need to perform this upgrade?

It is not mandatory that agencies upgrade to 1.3.0. However, users of recipe 1.1.2 and below must upgrade to at least recipe 1.2.0 by the 1st of March 2016, as it is being deprecated. This deprecation is necessary due to known security issues which may affect sites, and this upgrade is necessary to ensure that any site running on CWP is safe from possible attack.

In addition, there is a planned security upgrade for version 1.2.1 due to be released early next month, at which time 1.2.0 will become deprecated. This will be a minor upgrade to include framework version 3.2.3,  and will contain many of the same security fixes as recipe 1.3.0.

Agencies are expected to regularly carry out upgrades, because as time passes we end support for old versions. Please read our release management guide and CWP Versions and Support Deadlines and technical upgrade instructions for more information.

What is in release 1.3.0?

The upgrade to CMS and Framework 3.3 introduces a major UX overhaul with improved handling in the following areas:

• Ability to search pages in all edit views.
• Updated look and feel, with most elements receiving a theme overhaul.
• Additional security features to help construct and manage versioned DataObjects
• Additional security on the ?stage=Stage querystring parameter. Now by default, only users with any of the following permissions may set this option:
  1. "Access to all CMS sections"
  2. "Access to Pages section"
  3. "View draft content"

For more detailed information on what features are available in 3.3, what has changed, and reasons why you may or may not want to upgrade, you can see our blog post on the beta release. You can also read the 3.3 changelog for specific upgrading instructions.

The release notes for the CWP 1.3.0 Basic Recipe can be found here.

Details of security issues

This release includes fixes for the following issues:

• ss-2015-019: 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.
• 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