With the recent simultaneous release of both Magento 1.9.3.0 and SUPEE-8788, I decided to take some time and review the differences between an upgrade to 1.9.3.0 and patching an existing 1.9.2.4 installation. I did a similar thing when SUPEE-7405 came out alongside 1.9.2.4 and found that the differences were minimal. In this instance, however, the changeset between the upgrade and the patch are significant. Due to the number of difference I’ve decided to concentrate this post specifically on changes which could be deemed related to security.

Password Flow

The first new feature I came across was the addition of some configuration for ‘Password Flow’. This feature allows rate limiting of the forgot password functionality based on IP address and/or e-mail. The configuration for it can be found under System > Preferences > Admin > Security.

PHP 5.6 Support

Since PHP 5.5 is now EOL, which means that new 5.5 versions will be released and therefore no newly discovered issues will be patched. With the release of 1.9.3.0 PHP 5.6 is now officially supported. Whilst many vendors / merchants have been running on this for some time without issue, the official nod may help cut through corporate red tape with regards to using unsupported software. PHP 5.6 is in itself only a few months away from it’s EOL status, leaving an official decision to support 5.6 and not 7.0 seem somewhat shortsighted. But that’s another discussion.

RSS Admin Credential Validation

The admin actions which exist on the frontend RSS controllers now check if a feed is enabled before checking the credentials. This means if the feeds aren’t enabled, you can any longer use this endpoint to attempt to validate admin credentials. If you’re unfamiliar with this issue, I’m likely to cover it in more depth in a later post.

Hostname Validation

The Zend_Validate_Hostname validation was updated to add a DNS check of the A record for the domain.

Changing Customer E-mail or Password

In releases prior to 1.9.3.0 it was possible to change the e-mail address of a customer without knowing their password. This meant if you could gain temporary access to an account you could completely hijack it by changing the e-mail then using the forgotten password functionality. By doing so you would prevent the original owner from ever being able to regain the account (without assistance from an admin of course). In addition to this, a new e-mail is now sent out if the password or e-mail address of the account is changed. In the case of an e-mail change, this is obviously sent out to the old e-mail. If somebody does manage to get your password, this at least means you’ll get a notification that your account has been taken over.

nosniff Header

Prevents browsers from guessing at the content type of returned files. This can help protect against the browser being tricked by certain files containing content that doesn’t match the type of file. For example, JS embedded as header information in an image can lead to XSS attacks when sniffing isn’t prevented.

Forgotten Password Token Expiration

The ‘timout period’ of the tokens used in links sent out in the ‘forgot password’ e-mail now expires is now a measurement in hours, rather than days.

Session Expiration

Sessions now expired after the same amount of time as the session cookie. Previously it was possible to re-access the session even after the cookie timed out.

Downloader Bruteforce Protection

Attempting to log into the downloader now performs additional checks to prevent brute force attempts to validate a password. The default configuration for this means that you can only attempt to login 3 times every 3 minutes before being blocked.

Path Filtering

Various references to paths generated in the admin section of the site are now passed through the getFilteredPath method. The purpose of the function is to change a full path into a relative path. Looking at the usages of it, I’m assuming this is to avoid ‘leaking’ the full filesystem path.

Error Processor

A couple of theoretical issues have been fixed here. Firstly the hostname is being escaped. Since the Host header can be controlled by the request it could, in theory, contain an XSS vector. I’m not personally sure how you could exploit this. The closest I can come up with is if you could make the server cache the page you could theoretically use it as part of a CSRF attack against a user. For this to work, it would require that a.) The site doesn’t have the X-Frame-Options header set, b.) the VirtualHost catches all requests to the server, regardless of domain and c.) You have a caching mechanism that both caches the page and doesn’t use the HOST header in the cache key. If you can think of a way to exploit the host header not being escaped in this context, let me know.

The second issue that has been addressed is checking if the loaded report file contains a serialized object before attempting to unserialize. If an attacker could find a way to upload an arbitrary file into the reports directory, this check would help to prevent an RCE attack.

Conclusion

So as you can see, there are various security improvements in the update that are not present in the patch. Before running out to perform the upgrade, however, bear in mind that there have been numerous bugs reported. Most of these have been collated, along with a bug-fix module in this post by Raphael at Digital Pianism. So be sure to check that out before upgrading. Alternatively you could wait for a 1.9.3.1 release, which isn’t expected to be too far away.

If anybody spots any inaccuracies or security impacting changes I didn’t include, let me know.