2012-12-06 16:25:45 +01:00
|
|
|
# 3.0.4
|
|
|
|
|
|
|
|
## Overview
|
|
|
|
|
2013-02-17 22:33:04 +01:00
|
|
|
* Security: Information leakage through web access on YAML configuration files
|
|
|
|
* Security: Information leakage through web access on composer files
|
|
|
|
* Security: Require ADMIN permissions for `?showtemplate=1`
|
2013-01-04 18:21:26 +01:00
|
|
|
* Security: Reflected XSS in custom date/time formats in admin/security
|
|
|
|
* Security: Stored XSS in the "New Group" dialog
|
|
|
|
* Security: Reflected XSS in CMS status messages
|
2012-12-06 16:25:45 +01:00
|
|
|
* Changed `dev/tests/setdb` and `dev/tests/startsession` from session to cookie storage.
|
2013-02-12 23:23:18 +01:00
|
|
|
|
|
|
|
## Details
|
|
|
|
|
2013-01-04 18:21:26 +01:00
|
|
|
### Security: Information exposure through web access on YAML configuration files
|
2013-02-12 23:23:18 +01:00
|
|
|
|
2013-02-17 22:33:04 +01:00
|
|
|
Severity: Moderate
|
|
|
|
|
|
|
|
Description: YAML files are used to configure the SilverStripe application
|
|
|
|
since its 3.0 release. These files can contain sensitive values such as database
|
|
|
|
and API credentials. By default, the installer still stores database credentials
|
|
|
|
in `_config.php` files which are safe from web access. So this only concerns
|
|
|
|
configuration values added in your own project, or a third party module.
|
|
|
|
|
|
|
|
Resolution: Update your `.htaccess` file (for Apache), or your `web.config` file (for IIS)
|
|
|
|
with the new files from the project root, and reapply any customizations you've made.
|
|
|
|
Follow the [general upgrade instructions](/installation/upgrading).
|
|
|
|
The [nginx installation instructions](/installation/nginx)
|
|
|
|
have also been updated to reflect those changes.
|
|
|
|
|
|
|
|
### Security: Information exposure through web access on composer files
|
|
|
|
|
|
|
|
Severity: Low
|
|
|
|
|
|
|
|
Description: [Composer](http://getcomposer.org) is a dependency management
|
|
|
|
tool which can optionally be used to install SilverStripe. The `composer.json`
|
|
|
|
and `composer.lock` files are required for its operation, so they are included
|
|
|
|
in the standard release since 3.0.2. These files contain information on the installed
|
|
|
|
versions of core and thirdparty modules, which could be used to target specific
|
|
|
|
versions of SilverStripe.
|
|
|
|
|
|
|
|
Resolution: Update your `.htaccess` file (for Apache), or your `web.config` file (for IIS)
|
|
|
|
with the new files from the project root, and reapply any customizations you've made.
|
|
|
|
Follow the [general upgrade instructions](/installation/upgrading).
|
|
|
|
The [nginx installation instructions](/installation/nginx)
|
|
|
|
have also been updated to reflect those changes.
|
|
|
|
|
|
|
|
|
|
|
|
### Security: Require ADMIN permissions for `?showtemplate=1`
|
|
|
|
|
|
|
|
Severity: Low
|
|
|
|
|
|
|
|
Description: Avoids information leakage of compiled template data,
|
2013-02-12 23:23:18 +01:00
|
|
|
which might expose some of the internal template logic.
|
2012-12-06 16:25:45 +01:00
|
|
|
|
|
|
|
## Upgrading
|
|
|
|
|
2013-01-04 18:21:26 +01:00
|
|
|
### Security: Reflected XSS in custom date/time formats in admin/security
|
|
|
|
|
|
|
|
Severity: Low
|
|
|
|
|
|
|
|
Prerequisite: An attacker must have access to the admin interface.
|
|
|
|
|
|
|
|
Description: When creating a new user on the security page
|
|
|
|
(Security->New User) within the admin interface, the user input
|
|
|
|
is not properly validated and not encoded. A reflected XSS is
|
|
|
|
possible within the `DateFormat_custom` and `TimeFormat_custom` fields.
|
|
|
|
|
|
|
|
Credits: Andreas Hunkeler (Compass Security AG, http://www.csnc.ch)
|
|
|
|
|
|
|
|
### Security: Stored XSS in the "New Group" dialog
|
|
|
|
|
|
|
|
Severity: Low
|
|
|
|
|
|
|
|
Prerequisite: An attacker must have access to the admin interface.
|
|
|
|
|
|
|
|
Description: There is a stored XSS vulnerability on the "group" tab on the
|
|
|
|
security page in the admin interface
|
|
|
|
(Security -> Groups -> New Group). It's possible to store a
|
|
|
|
XSS within the group name. Everywhere where these group names
|
|
|
|
are used, the XSS is executed. E.g. "New User" or "New Group".
|
|
|
|
|
|
|
|
Credits: Andreas Hunkeler (Compass Security AG, http://www.csnc.ch)
|
|
|
|
|
|
|
|
### Security: XSS in CMS status messages
|
|
|
|
|
|
|
|
Severity: Low
|
|
|
|
|
|
|
|
Prerequisite: An attacker must have access to the admin interface.
|
|
|
|
|
|
|
|
Description: Any data returned to CMS status messages (Growl-style popovers on top right)
|
|
|
|
was not escaped, allowing XSS e.g. when publishing a page with
|
|
|
|
a specifically crafted "Title" field.
|
|
|
|
|
|
|
|
Credits: Andreas Hunkeler (Compass Security AG, http://www.csnc.ch)
|
|
|
|
|
|
|
|
### Misc
|
|
|
|
|
2012-12-06 16:25:45 +01:00
|
|
|
* If you are using `dev/tests/setdb` and `dev/tests/startsession`,
|
|
|
|
you'll need to configure a secure token in order to encrypt the cookie value:
|
|
|
|
Simply run `sake dev/generatesecuretoken` and add the resulting code to your `mysite/_config.php`.
|
|
|
|
Note that this functionality now requires the PHP `mcrypt` extension.
|