Magento has released a new security patch SUPEE-6788, and we would like to share our experience with its installation troubleshooting. We are describing this topic assuming that you’ve already checked a web store on magereport.com and implemented the security recommendations like closing access to var directory, downloader, changed the URL to the admin panel to more secure etc. We will also try to avoid the discussion of the admin routes compatibility here because the patch already contains the back routes compatibility. Therefore, the main goal of this article is to make your store functioning correctly after applying the patch.
First of all, you should download the patch for the corresponding of your web store Magento version from the official site by this link or follow the instructions in the received email from Magento support. So, just check your Magento version right in the app/Mage.php getVersionInfo() method. Alternatively, you can check the version in the admin panel – for example, these approaches are described in this article.
We should mention that we are writing the article right after the patch release, that is why, pay attention that there are no patches available for versions lower than 1.7.0. By the way, it is a good chance to think about upgrading your Magento store. However, we assume that patches for older versions should appear soon as well.
We recommend to make a backup before further steps.
Make sure that the patch is copied to the root folder of your Magento installation and run via ‘sh’ or ‘bash’ command (please note that the patch name may vary depending on your Magento store’s version):
bash PATCH_SUPEE-6788_CE_1.9.2.1_v1-2015-10-26-11-38-41.sh
The bash output should be short, like “Patch was applied/reverted successfully”. Otherwise, please check the bash output for any issues. Most often we meet the refuse to update the .htaccess file, especially for the Community Edition patches. In this case, it is recommended to back up and replace it with the default one. Then, if it does not help, we suggest more radical solution (but proceed with it for your own responsibility), simply remove the lines around 163-195 from the patch. That is the section responsible for the .htaccess update, it should start with the line:
diff --git .htaccess .htaccess
and end up with:
+ </Files>
Furthermore, if it helps apply the patch, then simply add these lines at the end of your .htaccess file:
###########################################
## Deny access to cron.php
<Files cron.php>
############################################
## uncomment next lines to enable cron access with base HTTP authorization
## http://httpd.apache.org/docs/2.2/howto/auth.html
##
## Warning: .htpasswd file should be placed somewhere not accessible from the web.
## This is so that folks cannot download the password file.
## For example, if your documents are served out of /usr/local/apache/htdocs
## you might want to put the password file(s) in /usr/local/apache/.
#AuthName "Cron auth"
#AuthUserFile ../.htpasswd
#AuthType basic
#Require valid-user
############################################
Order allow,deny
Deny from all
</Files>
Moreover, if you have troubles with the .htaccess.sample file – just implement similar operations as it was done for the .htaccess file. In case you’re using Nginx, please make sure that magent_root/cron.php is restricted from the web access – for this, add one line to the nginx host config:
server {
.......
#add this line to prevent web access to cron.php
location ^~ /cron.php { return 403; }
.......
}
Don’t forget to reload Nginx after updating its config.
We also had problems with magento_root/cron.php update. Note that the issue can be solved by replacing it with the original one. In addition, it is also possible that you may have insufficient permissions to apply the patch. Try to run it with “sudo” – it should help in this case.
Next step is to check if you have any files impacted by the patch override. And here the version control was very helpful for us. We had the development environments under the git version control, so we could easily track such situations. Most of the updated files are really deep in the core structure and you should not have troubles with it, but be cautious. Most obvious places that you will have to check after applying the patch are:
1. Any class that overrides Mage_Customer_AccountController (magento_root/app/code/core/Mage/Customer/controllers/AccountController.php).
2. Customer registration form may be overridden with the custom design theme. You will simply need to add a form key right after the “form” tag:
<input type="hidden" name="form_key" value="<?php echo Mage::getSingleton('core/session')->getFormKey() ?>" />
Affected templates are:
- magento_root/app/design/frontend/base/default/template/customer/form/register.phtml
- magento_root/app/design/frontend/base/default/template/persistent/customer/form/register.phtml
- magento_root/app/design/frontend/rwd/enterprise/template/customer/form/register.phtml
For Enterprise Edition also:
- magento_root/app/design/frontend/enterprise/default/template/customer/form/register.phtml
- magento_root/app/design/frontend/enterprise/default/template/persistent/customer/form/register.phtml
- magento_root/app/design/frontend/rwd/enterprise/template/customer/form/register.phtml
- magento_root/app/design/frontend/rwd/enterprise/template/persistent/customer/form/register.phtml
3. Reset forgotten password form can be also overridden. Replace the “form” opening tag with this one:
<form action="<?php echo $this->getUrl('*/*/resetpasswordpost'); ?>" method="post" id="form-validate">
Affected templates are:
- magento_root/app/design/frontend/base/default/template/customer/form/resetforgottenpassword.phtml
- magento_root/app/design/frontend/rwd/default/template/customer/form/resetforgottenpassword.phtml
For Enterprise Edition also:
- magento_root/app/design/frontend/enterprise/default/template/customer/form/resetforgottenpassword.phtml
4. Customer layout “customer_account_resetpassword” is replaced with “customer_account_changeforgotten”. So, if you have magento_root/app/design/frontend/custom_package/custome_theme/layout/customer.xml or custom theme with that file in “default”, “rwd” or “enterprise” packages, replace:
<customer_account_resetpassword translate="label">
.........
</customer_account_resetpassword>
with:
<customer_account_changeforgotten translate="label">
<label>Reset a Password</label>
<remove name="right"/>
<remove name="left"/>
<reference name="head">
<action method="setTitle" translate="title" module="customer">
<title>Reset a Password</title>
</action>
</reference>
<reference name="root">
<action method="setTemplate">
<template>page/1column.phtml</template>
</action>
<action method="setHeaderTitle" translate="title" module="customer">
<title>Reset a Password</title>
</action>
</reference>
<reference name="content">
<block type="customer/account_changeforgotten" name="changeForgottenPassword" template="customer/form/resetforgottenpassword.phtml"/>
</reference>
</customer_account_changeforgotten>
After applying the patch you may find that some of your custom pages are missing the content. That is because the patch is adding validation for {{block type=”…” …}} and {{config path=’…’}} magic quotes. The allowed block types are stored in ‘permission_block’ database table and contain only two records: ‘core/template’ and ‘catalog/product_new’, and the allowed config paths are stored in ‘permission_variable’ database table and have more records:
+-------------+-----------------------------------+------------+ | variable_id | variable_name | is_allowed | +-------------+-----------------------------------+------------+ | 1 | trans_email/ident_support/name | 1 | | 2 | trans_email/ident_support/email | 1 | | 3 | web/unsecure/base_url | 1 | | 4 | web/secure/base_url | 1 | | 5 | trans_email/ident_general/name | 1 | | 6 | trans_email/ident_general/email | 1 | | 7 | trans_email/ident_sales/name | 1 | | 8 | trans_email/ident_sales/email | 1 | | 9 | trans_email/ident_custom1/name | 1 | | 10 | trans_email/ident_custom1/email | 1 | | 11 | trans_email/ident_custom2/name | 1 | | 12 | trans_email/ident_custom2/email | 1 | | 13 | general/store_information/name | 1 | | 14 | general/store_information/phone | 1 | | 15 | general/store_information/address | 1 | +-------------+-----------------------------------+------------+
So, if you’re adding any custom block or config value to your email template, newsletter, widget, CMS page, CMS block, category or product description (please let us know if we’ve missed something) – they won’t be rendered and, most likely, you will receive an error in your magento_root/var/log/system.log like this:
2015-10-29T00:00:00+00:00 ERR (3): Notice: Undefined variable: block in magento_root/app/code/core/Mage/Core/Model/Email/Template/Filter.php on line 187 2015-10-29T00:00:00+00:00 ERR (3): Notice: Undefined variable: block in magento_root/app/code/core/Mage/Core/Model/Email/Template/Filter.php on line 197
That is why, you should try to find all the places with passible magic quotes usage and add custom config paths and block types to the allowed list. The easiest way to do this is by using MySQL queries like here (note that we were searching for the most common places, widget tables and any custom tables, like custom newsletters or blog pages are not included):
SELECT `identifier`, `content` FROM `cms_block` WHERE `content` LIKE '%{{block%}}%' OR `content` LIKE '%{{config path=%}}%';
SELECT `identifier`, `content` FROM `cms_page` WHERE `content` LIKE '%{{block%}}%' OR `content` LIKE '%{{config path=%}}%';
SELECT `value` FROM `catalog_product_entity_text` WHERE `value` LIKE '%{{block%}}%' OR `value` LIKE '%{{config path=%}}%';
SELECT `value` FROM `catalog_product_entity_varchar` WHERE `value` LIKE '%{{block%}}%' OR `value` LIKE '%{{config path=%}}%';
SELECT `value` FROM `catalog_category_entity_text` WHERE `value` LIKE '%{{block%}}%' OR `value` LIKE '%{{config path=%}}%';
SELECT `value` FROM `catalog_category_entity_varchar` WHERE `value` LIKE '%{{block%}}%' OR `value` LIKE '%{{config path=%}}%';
SELECT `template_code`, `template_text` FROM `core_email_template` WHERE `template_text` LIKE '%{{block%}}%' OR `template_text` LIKE '%{{config path=%}}%';
SELECT `template_code`, `template_text` FROM `newsletter_template` WHERE `template_text` LIKE '%{{block%}}%' OR `template_text` LIKE '%{{config path=%}}%';
Also, check the local directory of your Magento installation or even the whole Magento files, email templates with custom blocks – the issues may be also there.
After finding all the necessary records simply add them to the database. We will do this via an install script. If you do not have any module to add an install script, create a new one. Module declaration:
<?xml version="1.0"?>
<!-- path: magento_root/app/etc/modules/Atwix_Addallowed.xml -->
<config>
<modules>
<Atwix_Addallowed>
<active>true</active>
<codePool>local</codePool>
<depends>Mage_Admin</depends>
</Atwix_Addallowed>
</modules>
</config>
Install script declaration in the config.xml :
<?xml version="1.0"?>
<!-- path: magento_root/app/code/local/Atwix/Addallowed/etc/config.xml -->
<config>
<modules>
<Atwix_Addallowed>
<version>1.0.0</version>
</Atwix_Addallowed>
</modules>
<global>
<resources>
<atwix_addallowed>
<setup>
<module>Atwix_Addallowed</module>
</setup>
</atwix_addallowed>
</resources>
</global>
</config>
The install script itself:
<?php
/**
* path magento_root/app/code/local/Atwix/Addallowed/sql/atwix_addallowed/install-1.0.0.php
*/
$installer = $this;
$installer->startSetup();
/**
* Adding allowed blocks to Mage_Core_Model_Email_Template_Filter after SUPEE-6788 install
*/
$allowedBlocksArray = array(
'cms/block',
'custom/block_type'
);
foreach ($allowedBlocksArray as $item) {
try {
Mage::getModel('admin/block')->setData('block_name', $item)
->setData('is_allowed', 1)
->save()
;
} catch(Exception $e) {
Mage::log($e->getMessage(), null, 'atwix_add_allowed.log', true);
}
}
/**
* Adding allowed blocks to Mage_Core_Model_Email_Template_Filter after SUPEE-6788 install
*/
$allowedConfigArray = array(
'custom/config/path',
);
foreach ($allowedConfigArray as $item) {
try {
Mage::getModel('admin/variable')->setData('variable_name', $item)
->setData('is_allowed', 1)
->save()
;
} catch(Exception $e) {
Mage::log($e->getMessage(), null, 'atwix_add_allowed.log', true);
}
}
$installer->endSetup();
In addition, we’ve noticed that M2EPro extension stops working after the patch installation. Please address this issue to their support, and as a temporary solution, you may copy app/code/community/Ess/M2ePro/Model/Config/Abstract.php to app/code/local/Ess/M2ePro/Model/Config/Abstract.php and replace all the ‘`’ symbols from it – this should help.
We hope that the information provided about the patch installation was helpful. Please feel free to add your own findings to the comments, they will be useful for us and other developers. Thanks for reading us and feel free to check more info on the Magento Security Patches!
UPDATE: We’ve noticed that Aoe_Scheduler extension may be broken by this patch. The extension update is released, please check it.
You may also want to read:
