Security Patch SUPEE-9767 - Possible issues?

https://magento.stackexchange.com/questions/176871

09-10-2020
|

문제

A new security patch is out for Magento 1, addressing 16 APPSEC issues: https://magento.com/security/patches/supee-9767

Seven of the vulnerabilities score 8.0 or higher for CVSSv3 Severity, and they are being exploited in the wild, so this is a critical patch. Sites can apply SUPEE-9767, or update to the new release CE 1.9.3.3 / EE 1.14.3.3.

What are common issues or pitfalls to watch out for when applying SUPEE-9767?

UPDATE 2017-07-12:

Magento has released SUPEE-9767 V2 and CE 1.9.3.4 to address many of the issues from the initial patch. If you applied V1, you should revert and then apply V2. If you haven't patched yet, just apply V2, and most of the issues brought up here will not be relevant.

해결책

Here's my overview of the patch after digging into it

TIME SAVER : Experius provides a patch helper that helps you finding the files in custom themes, custom modules or local overwrites that also might need to be patched manually, you can find it here: https://github.com/experius/Magento-1-Experius-Patch-Helper#magento

Checkout form keys

As said in the other post, this patch adds form keys to the following forms:

Shipping cart form:

app/design/frontend/<package>/<theme>/template/checkout/cart/shipping.phtml

Multishipping billing checkout form:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/billing.phtml

Multishipping shipping checkout form:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/shipping.phtml

Multishipping addresses checkout form:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/addresses.phtml

Billing checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/billing.phtml

Shipping checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping.phtml

Payment checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/payment.phtml

Shipping method checkout form:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping_method.phtml

Persistent Billing checkout form:

app/design/frontend/<package>/<theme>/template/persistent/checkout/onepage/billing.phtml

On top of that the following JS files have been updated to be compatible with that change:

js/varien/payment.js
skin/frontend/base/default/js/opcheckout.js

What to do:

If you're using with custom versions of those templates you'll have to update them by adding the following code into them:

<?php echo $this->getBlockHtml('formkey') ?>

If you're using a 3rd party checkout module, you'll have to get in touch with them so they can provide an updated version of their module.

Also if you have custom versions of the previously listed JS files, you'll have to update them too.

SAVE YOUR TIME:

Fabian Schmengler wrote a nice little script to update all those things for you, you can find it here:

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

IMPORTANT NOTE : the checkout formkey validation can be changed in the backend via a new config field under System > Configuration > Admin > Security > Enable Form Key Validation On Checkout . THIS IS NOT ENABLED BY DEFAULT so you'll have to enable it to benefit from this security feature!!! Note that you'll get a notice in the backend if it's not enabled.

Image Upload callback

The image gallery controller has been updated to add a validation callback.

What to do

If you're using a custom module that does image upload with code that looks like this:

        $uploader = new Mage_Core_Model_File_Uploader('image');
        $uploader->setAllowedExtensions(array('jpg','jpeg','gif','png'));
        $uploader->addValidateCallback('catalog_product_image',
            Mage::helper('catalog/image'), 'validateUploadFile');
        $uploader->setAllowRenameFiles(true);
        $uploader->setFilesDispersion(true);

I strongly suggest you update that code by adding the following piece after it:

        $uploader->addValidateCallback(
            Mage_Core_Model_File_Validator_Image::NAME,
            Mage::getModel('core/file_validator_image'),
            'validate'
        );

Symlinks

This patch removes the system configuration field that allows you to allow template symlinks in the backend. It used to be under System > Configuration > Developer > Template > Allow Symlinks . Now the entire Template section is gone.

On top of that, that field is now disabled by default via the app/etc/config.xml

The funny thing here is that you'll get a notice in the backend if you have that configuration field enabled prior to the patch but you won't be able to disable it as the field is gone.

Only way of doing it is by running the following SQL query

UPDATE core_config_data SET value = 0 WHERE path = "dev/template/allow_symlink";

Clarification

First I strongly suggest you check those two posts that will help you understand the purpose of that Symlink modification:

From Peter O'Collaghan: https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/
From Max Chadwick: https://maxchadwick.xyz/blog/what-allow-symlinks-actually-does

This modification is really about calling uploadable content (like images) via template directives.

Please note that they are some protections against known way to exploit it in addition to the setting itself.

What to do: if like me, you're using modman or composer with template symlinks, you're gonna face some issues. I'm still trying to find out what's the best thing to do here apart from dealing with SQL queries.

Main post regarding this issue: SUPEE-9767, modman and symlinks

List of possible issues

V2 was released since that original post. Don't forget to upgrade

Bugs

The word 'confirmed' is used for confirmed bugs. If it's not there, that means it could be a bug but hasn't been confirmed yet.

Customer registration fails at checkout CONFIRMED & FIXED IN V2
PHP7 and EE bug CONFIRMED
Bug with EE, FPC and Design Exceptions CONFIRMED
Add to cart and cookie bug in EE CONFIRMED
Multishipping broken after patch CONFIRMED
Missing bug fix in head-simple.phtml CONFIRMED & FIXED IN V2
Admin Symlink warning is not displayed on 1.9.2 CONFIRMED & FIXED IN V2
Watermark get black background when transparent CONFIRMED & FIXED IN V2
Unable to upgrade via Magento Connect
Infinite redirect loop on 1.6.0.0

Hunk Failed Issues

Note that all those issues could be simply because you modified the original file, to double check that this is not the case:

Backup the file where you get the Hunk Failed error
Download the original file from your Magento version
Compare both files

If files are different you'll have to apply the patch with the original file then reapply your custom changes the clean way such as:

custom template in a custom theme folder
local.xml
app/code/local file

If files are not different then this is either a permission issue or a "bug" in the patch.

다른 팁

Issue1: form_key invalid at checkout onepage

Magento add form_key at most of the forms.

if you have using default onepage and using custom theme, then you will start getting **form_key issue at checkout each step **;

you should add form key at <?php echo $this->getBlockHtml('formkey') ?>

to form of each checkout step files if below files exits,

app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/billing.phtml
app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/payment.phtml
app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping.phtml
app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping_method.phtml

if the template files are calling from base theme then it does not create problem.Because patch will automatically update those files.

Also note: <?php echo $this->getBlockHtml('formkey') ?> should always inside of form tag

 <form action="" .....>
     <fieldset>
      .......
       <?php echo $this->getBlockHtml('formkey') ?>
     </fieldset>
 </form>

** If you using Magento multi-shipping checkout then need to done at

below files:

Issue2: form_key issue to Shipping estimation form at cart page:

Add form_key at estimates shipping form at cart page

Then must add form key <?php echo $this->getBlockHtml('formkey') ?>

at app/design/frontend/{Your_Package}/{YOUR_THEME]/template/checkout/cart/shipping.phtml

Issue3: Magento onepage checkout opcheckout.js error

If you using default onepage checkout and have opcheckout.js then should check

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {is available at opcheckout.js

If not exits then replace

if (elements[i].name=='payment[method]') {

with

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

For case of issue1,issue2, issue3, Issue can fix easily by using @FabianSchmengler 's script add-checkout-form-key.sh. It will fix the issue on your receptive theme files

Issue4: Invalid form key after customer login when Mage_Customer_Model_Session rewrite

If Mage_Customer_Model_Session class rewrite or have called from

app/code/local/Mage/Customer/Model/Session.php then you may be get form_key issue when we set a customer for the session using setCustomerAsLoggedIn() /or after a customer set at session .

In this case, you must be add

Mage::getSingleton('core/session')->renewFormKey();

at setCustomerAsLoggedIn() before call of

Mage::dispatchEvent('customer_login', array('customer'=>$customer));

  public function setCustomerAsLoggedIn($customer)
    {
        $this->setCustomer($customer);
        $this->renewSession();
        // add this  for patch -9767
        Mage::getSingleton('core/session')->renewFormKey();
       // end this for patch 9767
        Mage::dispatchEvent('customer_login', array('customer'=>$customer));
        return $this;
    }

Issue5: Form_key issue after logout

After logout customer from session, you may be start session issue if If Mage_Customer_Model_Session class rewrite or have called from

app/code/local/Mage/Customer/Model/Session.php

In those same need for this case:

   protected function _logout()
    {
        $this->setId(null);
        $this->setCustomerGroupId(Mage_Customer_Model_Group::NOT_LOGGED_IN_ID);
        $this->getCookie()->delete($this->getSessionName());
// add this  for patch -9767
Mage::getSingleton('core/session')->renewFormKey();
        return $this;
    }

Recommendation:

Recommendation1: For fixed the issue of supee-9767, you can use the patch https://github.com/experius/Magento-1-Experius-Patch-Helper

This is one best solution for now.

Note, before do that I am strongly recommended to take files and database backup or full system backup.

Recommendation2: Use patch feature on your ONESTEP CHECKOUT

We know that patch supee-9767 release for security purpose, the if you using ONESTEP CHECKOUT then you should add form_key validation to SAVE action of your onestep checkout controller.

Suppose for save shipping method details, your onestep checkout have using saveShippingmethod() Then on this you should add

if ($this->isFormkeyValidationOnCheckoutEnabled() && !$this->_validateFormKey()) {
           return;
      }

Also on youmust add form key <?php echo $this->getBlockHtml('formkey') ?> at your onestep checkout phtml files respective section

Some related link

https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/

Based on my first pass at review of the patch file...

A new setting admin/security/validate_formkey_checkout has been added. When turned on, checkout forms are checked for presence of a form key. If the template files are overriden in the theme they'll need to be updated there. This setting seems to be off by default
Symlinks seem to be disallowed by default (in app/etc/config.xml). Also, the ability to allow them seems to have been removed from the admin configuration. However, if your site previously explicitly enabled symlinks, the setting would be saved in the database, overriding this change.
You need to clear both the cache AND the full page cache when applying this patch. The design exceptions are saved in a format the is incompatible with decoding. You'll see an error like this "Decoding failed: Syntax error" if you don't flush page cache.

Below base/default file affected with this patch, if this files were in your theme then please make changes accordingly

app/design/frontend/base/default/template/checkout/cart/shipping.phtml

app/design/frontend/base/default/template/checkout/multishipping/billing.phtml

app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/billing.phtml

app/design/frontend/base/default/template/checkout/onepage/payment.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml

app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml

in all above phtml files below form key line is added so please add this line in your respective phtml file.

 <?php echo $this->getBlockHtml('formkey') ?>

For above issue @fabian created a script which will add form key even in your theme file

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

after applying security patch if you get error for form key you can apply this patch , for applying this patch process is same as security patch just

  sh filename.sh

and one base/default change in Js file

  skin/frontend/base/default/js/opcheckout.js

so if this js file is loading from your theme then do below steps

remove blow line

 if (elements[i].name=='payment[method]') {

and add below line instead of above

 if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

EDIT

And if you are using any checkout extension which overrides below files then add form key line in checkout extension's phtml file.

EDIT2 -- Issues

1) Error at saveBillingAction() or getting form key null Or Form Key issue : Patch 9767 getting invalid Form Key

2) Hunk #1 FAILED at 225. 1 out of 1 hunk FAILED -- saving rejects to file app/design/frontend/enterprise/default/template/persistent/checkout/onepage/billing.phtml : SUPEE-9767 - Hunk #1 FAILED at 225. 1 out of 1 hunk FAILED

3) saving rejects to file app/code/core/Enterprise/PageCache/Model/Observer.php.rej : SUPEE-9767 ERROR: Patch can't be applied/reverted successfully

4) SUPEE-9767, modman and symlinks : SUPEE-9767, modman and symlinks

5) app/design/frontend/rwd/default/layout/page.xml Hunk #1 FAILED at 36. Hunk #2 FAILED at 54. 2 out of 2 hunks FAILED : SUPEE-9767 Error

6) 1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php : Magento 1.9.2.2 SUPEE-9767 Patch ERROR

7) onestep checkout error (again this is the form key issue) : SUPEE-9767 Magento CE 1.9.3.3 Onestep Checkout not working with Form Key Validation On Checkout enabled

8) one step checkout customer registration issue : SUPEE-9767 Patch/CE 1.9.3.3 - One Page Checkout - Customer Registration issue

9) app/code/core/Mage/Core/Model/File/Validator/Image.php : Magento SUPEE 9697 1.9.2.2 fails at Image.php

Note that Symlinks have always been disabled by default on new Magento installations admin YES/NO config values default to 'NO'. The update now explicitly disables symlinks in config.xml and as an extra precaution also removes the template section from admin->developer which contained the configuration option.

This will not affect your current symlink settings, if you manually enabled symlinks prior to 1.9.3.2 they will stay enabled, although you cannot see the setting anymore in admin.

Users using modman to manage Magento 1.x modules should ensure that they do not disable symlinks as this will disable the modman modules.

Responsible admins can enable the symlink admin section again by looking for the diff changes to the template section in app/code/core/Mage/Core/etc/system.xml and adding the section to your system.xml at around line 600. Or double check symlinks are still enabled with

n98-magerun.phar config:dump | grep symlink

Here is the diff file for magento1933 and magento1932 to assist with identifying changes in the default theme which may affect your custom/extended themes.

diff -r magento1933 magento1932 > https://pastebin.com/ADzMBLhr

Issue: Using php7 sometimes throws the following error:

Decoding failed: Syntax error

#0 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(179): Zend_Json::decode('')
#1 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(215): Enterprise_PageCache_Model_Observer->_loadDesignExceptions()
#2 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(125): Enterprise_PageCache_Model_Observer->_saveDesignException()
#3 /______/app/code/core/Mage/Core/Model/App.php(1358): Enterprise_PageCache_Model_Observer->cacheResponse(Object(Varien_Event_Observer))
#4 /______/app/code/core/Mage/Core/Model/App.php(1337): Mage_Core_Model_App->_callObserverMethod(Object({custom extensio}_Model_Rewrite_PageCache_Observer), 'cacheResponse', Object(Varien_Event_Observer))
#5 /______/app/Mage.php(456): Mage_Core_Model_App->dispatchEvent('controller_fron...', Array)
#6 /______/app/code/core/Mage/Core/Controller/Varien/Front.php(182): Mage::dispatchEvent('controller_fron...', Array)
#7 /______/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#8 /______/app/Mage.php(691): Mage_Core_Model_App->run(Array)
#9 /______/index.php(105): Mage::run('brandfield_nl', 'store')
#10 {main}

Its pretty sure that Zend version has to do something with it. A fast fix is this but is for sure not correct:

-> app/code/core/Enterprise/PageCache/Model/Observer.php:244 replace it with:

    if ($cachedSslOffloaderHeader !== false) {
        $cachedSslOffloaderHeader = trim(@Zend_Json::decode($cachedSslOffloaderHeader));
    }

-> and app/code/core/Enterprise/PageCache/Model/Observer.php:177 with:

    if ($exceptions !== false) {
        $exceptions = Zend_Json::decode($exceptions);
    }

Of course create an addon to rewrite this. But I am sure there is something better to be done here.

UPDATE (Better solution)

-> Go to: lib/Zend/Json.php and after the line 76 add this:

    if ((float)phpversion() >= 7.0
        && empty($encodedValue)
    ) {
        return null;
    }

Create your extension to override it and dont edit the core file.

Issue: Dynamic code or css disables form key input element at checkout

An issue I have seen is where dynamic code (paypal plus) in the one page checkout process overwrites the fieldset element in the one step payment method form html - deleting or disabling (with css) the hidden form_key element.

The fix is to ensure the formkey element is not being disabled by any dynamic code or css. Moving the formkey code outside of the fieldset element may also help

<form>
    <?php echo $this->getBlockHtml('formkey') ?>
    <fieldset>
        <?php echo $this->getChildHtml('methods') ?>
    </fieldset>
</form>

You can easily confirm if the form_key is being detected and sent to the one page controller by inspecting the ajax network requests in your browser as you move through the checkout methods, each method should include the form key in the ajax form data, if the form key is not there but the Magento source code has been patched check for external code affecting the form key element, i.e. css or dynamic client side changes.

Issue: Missing fixes in head-simple.phtml

app/design/adminhtml/default/default/template/oauth/authorize/head-simple.phtml

need the same fixes as

app/design/adminhtml/default/default/template/page/head.phtml

ISSUE: Customer Registration Fails when using generic Magento 5-step checkout.

This issue is only presented when we ENABLE form key authentication. Version used: 1.7.0.2, but looks like someone has posted that same issue occurs on 1.9.3 version too. SUPEE-9767 Patch/CE 1.9.3.3 - One Page Checkout - Customer Registration issue

When Go to checkout, we are presented with 2 options: CHECKOUT AS A GUEST OR REGISTER Once click "Register", and fill-out the form along with password, you proceed throguh all steps and complete the order. Order gets placed, BUT customer never gets registered in magento. It looks like Guest placed order.

When I went back and Disabled form key authentication, and tried placing order while registering as a customer, it got placed without any problems and the customer got registered in the backend.

UPDATE 13/07/2017 [ THE ISSUE IS FIXED ]

Magento team has released SUPEE-9767 V2 in this version of the patch the problem with transparent gif's and png's is fixed.

You should revert all changes to the file that was discussed in this thread. Then revert the applied V1 patch and finally apply the new version V2.

PRE - SUPEE-9767 V2

Please don't use the code discussed bellow instead apply V2 of the patch the problem discussed bellow is already fixed in this version

If somebody experience problem with transparent png's that when uploaded from the admin panel the background becomes black. (On the products) is in relation to the Image Upload callback introduced in:

app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

In the moment I am not sure what exactly is causing this behaviour but I am trying to figure it out I can confirm that when the callback is removed the strange behaviour is going away.

UPDATE

Ok, I found the function that is also updated from SUPEE-9767 this is actually breaking the transparency in the png's a copy of the original image is created without transparency.

+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
@@ -87,10 +87,33 @@ public function setAllowedImageTypes(array $imageFileExtensions = array())
      */
     public function validate($filePath)
     {
-        $fileInfo = getimagesize($filePath);
-        if (is_array($fileInfo) and isset($fileInfo[2])) {
-            if ($this->isImageType($fileInfo[2])) {
-                return null;
+        list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
+        if ($fileType) {
+            if ($this->isImageType($fileType)) {
+                //replace tmp image with re-sampled copy to exclude images with malicious data
+                $image = imagecreatefromstring(file_get_contents($filePath));
+                if ($image !== false) {
+                    $img = imagecreatetruecolor($imageWidth, $imageHeight);
+                    imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
+                    switch ($fileType) {
+                        case IMAGETYPE_GIF:
+                            imagegif($img, $filePath);
+                            break;
+                        case IMAGETYPE_JPEG:
+                            imagejpeg($img, $filePath, 100);
+                            break;
+                        case IMAGETYPE_PNG:
+                            imagepng($img, $filePath);
+                            break;
+                        default:
+                            return;
+                    }
+                    imagedestroy($img);
+                    imagedestroy($image);
+                    return null;
+                } else {
+                    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
+                }
             }
         }
         throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));

UPDATE

Here is updated version of the function to preserve the png transparency

  imagealphablending($img, false);
  imagesavealpha($img, true);

these two lines need to be added to the patch. Update the function in app/code/core/Mage/Core/Model/File/Validator/Image.php

/**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                imagealphablending($img, false);
                imagesavealpha($img, true);  
                imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

UPDATE 23/06/17

This updated version of the function fixes the PNG and the GIF transparency.

    /**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagecolortransparent($img, imagecolorallocatealpha($img, 0, 0, 0, 127));
                        imagealphablending($img, false);
                        imagesavealpha($img, true);
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagealphablending($img, false);
                        imagesavealpha($img, true);  
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

Issue: Allow symlink notification not shown to admins

The symlink notification will not be shown in the admin notification area as it is not included in the <block type="core/text_list" name="notifications" as="notifications">

The patch for both CE and EE below:

--- app/design/adminhtml/default/default/layout/main.xml
+++ app/design/adminhtml/default/default/layout/main.xml
@@ -119,7 +119,8 @@ Default layout, loads most of the pages
<block type="adminhtml/cache_notifications" name="cache_notifications" template="system/cache/notifications.phtml"></block>
<block type="adminhtml/notification_survey" name="notification_survey" template="notification/survey.phtml"/>
<block type="adminhtml/notification_security" name="notification_security" as="notification_security" template="notification/security.phtml"></block>
-            </block>
+                <block type="adminhtml/checkout_formkey" name="checkout_formkey" as="checkout_formkey" template="notification/formkey.phtml"/></block>
+                <block type="adminhtml/notification_symlink" name="notification_symlink" template="notification/symlink.phtml"/>
<block type="adminhtml/widget_breadcrumbs" name="breadcrumbs" as="breadcrumbs"></block>
<!--<update handle="formkey"/> this won't work, see the try/catch and a jammed exception in Mage_Core_Model_Layout::createBlock() -->

The issue is </block> is at the end of checkout_formkey (which is self-terminating) and therefore closes the parent notifications. This causes the notification_symlink to not be included in the core/text_list and not be rendered.

Little tip for #patchday; after copying 1.9.3.3 over your install, run git diff -w --stat | grep -v " 2 +" | grep -v " 0" to quickly see bigger changes in files.

Issue: EE shipping template not patched

I patched an EE 1.13.1.0 install, and the enterprise shipping template (app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml) did not have the formkey added, but the billing and payment templates did.

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml was patched.

There is an issue with Magento EE versions that are patched with SUPEE-9767 (so not with upgrades to 1.14.3.3). The form key on that page will be cached. So when I flush my cache and then go to a product page and make sure the page is completely cached (refresh a couple of times), I should be able to add that product to my cart.

Now, when I open a different browser (or incognito mode), open the same page and try to add the product to the cart again. The product will not be added to cart, because of the form key. Now when you flush the cache again, the product can be added to the cart again.

Thanks to Jasper Zeinstra

For developers using Magento Composer Intaller, you can change the deployment strategy to Copy instead of Symlink. You can also configure to append the module files to your .gitignore, so your repository will stay clean.

https://github.com/Cotya/magento-composer-installer/blob/master/doc/Deploy.md#deploy-per-copy-instead-of-symlink

{ "extra":{ "magento-root-dir": "htdocs/", "magento-deploystrategy": "copy", "auto-append-gitignore": true } }

I had an issue on EE 1.14.2.2 with FPC enabled and this patch applied.

Intermittently users could not add to cart.

Explanation and fix here: SUPEE-9767 issue : Add to cart issue, Enterprise Full Page Cache

Issue: Patch was working on vanilla Magento 1.7.0.0 [edited]

During the testing of our patch script we discovered a problem in the patch for Magento 1.7.0.0. Don't know if anybody still uses it, but anyhow it is a problem in SUPEE-9767. We used a vanilla install and we installed all previous patches first.

Patch file used: PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh The patch file does work for Magento 1.7.0.1 and 1.7.0.2

Summary of problems:

ERROR: Patch can't be applied/reverted successfully.
...
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
...
checking file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED
...

For the record, this on on the 1.7.0.0 we tried the patch on:

$ grep SUPEE app/etc/applied.patches.list
2017-06-01 12:59:49 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
-e 2017-06-01 12:59:49 UTC | SUPEE-1049 | EE-1.12.0.2 | v1 | 6d06f286f461562fa6d6573349f1491f7bf89859 | Wed Feb 13 17:46:13 2013 -0800 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-01 12:59:49 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-01 12:59:49 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-01 12:59:49 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-01 12:59:49 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-01 12:59:49 UTC | SUPEE-6788 | CE_1.7.0.1 | v1 | 04d237d56b116989e46839c41691585d927f99db | Fri Oct 23 13:52:50 2015 +0300 | f69136a
2017-06-01 12:59:49 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-01 12:59:50 UTC | SUPEE-8788 | CE_1.7.0.0 | v2 | 6b5ef4fc5b09af74d0fd401440948d0a54dd203d | Fri Oct 14 19:27:22 2016 +0300 | 84fa3dd598466fa5c482965a3f8e5395af33bf9d
2017-06-01 12:59:50 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-01 12:59:50 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523

I just had to revert this patch due to some strange behavior. For whatever reason, certain users could not add certain items to their cart.

I'm assuming it has something to do with old quotes colliding with the current quote for that customer. I verified this issue by logging in as the user to make sure it wasn't just a 1D10T.

It's been an issue since I took that patch life last Friday. We are using 1.14.2.4. We are heavily modified so it might work fine for other users. Just a warning!

Issue: Infinite redirect loop on 1.6.0.0

Quick Fix

Find the below lines inside the method protected function _checkBaseUrl($request) in the file app/code/core/Mage/Core/Controller/Varien/Front.php

 if (isset($uri['scheme']) && $uri['scheme'] != $request->getScheme()
        || isset($uri['host']) && $uri['host'] != $request->getHttpHost()
        || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) {

Change these lines to

 if (isset($uri['host']) && $uri['host'] != $request->getHttpHost()
            || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) {

After that save the file (commit to your REPO), clear the cache (remove everything inside var/cache folder) and reload your store front. You should find the site loads without anymore 302 redirect issues after applying the SUPEE 9767 Patch.

Root Cause

The difference in SCHEME value between the actual Request and the URI after redirection. Eg: The actual request returns the scheme HTTP but the scheme in the URI can be HTTPS.

Possible Underlying Reasons

You may most likely have a redirect rule in .htaccess file to redirect all the http requests to https. The user requests http://yourdomain.com and you may have changed the scheme and redirected him to https://yourdomain instead of http://yourdomain.com which he had actually requested.
Both the base secure and unsecure URLs begin with https

The CONFIRMED BUG "Customer registration fails at checkout" occurred a bit different on my side.

If the customer choose register in checkout then its password is not correctly stored. The customer is created correctly just that the password is not stored. I detected this by the fact that the password was not shown in welcome email. People can't login because of this too.

Bugfix linked in SUPEE-9767 Patch/CE 1.9.3.3 - One Page Checkout - Customer Registration issue has done the job for me too.

Can anyone tell me what the f... is this s... for in supee-9767?

The patch doesn't work even for a vanilla Magento 1.7.0.2.

martins@martinsmac.local:/var/www/magento1702-original$ ./PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Mage/Admin/Model/Session.php
Hunk #1 succeeded at 109 (offset -29 lines).
patching file app/code/core/Mage/Adminhtml/Block/Checkout/Formkey.php
patching file app/code/core/Mage/Adminhtml/Block/Notification/Symlink.php
patching file app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Date.php
patching file app/code/core/Mage/Adminhtml/Model/Config/Data.php
patching file app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php
patching file app/code/core/Mage/Checkout/controllers/MultishippingController.php
patching file app/code/core/Mage/Checkout/controllers/OnepageController.php
Hunk #1 succeeded at 293 (offset -34 lines).
Hunk #2 succeeded at 313 (offset -34 lines).
Hunk #3 succeeded at 363 (offset -34 lines).
Hunk #4 succeeded at 392 (offset -34 lines).
Hunk #5 succeeded at 431 (offset -34 lines).
patching file app/code/core/Mage/Checkout/etc/system.xml
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/Controller/Front/Action.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 141 (offset -7 lines).
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
patching file app/code/core/Mage/Core/etc/config.xml
patching file app/code/core/Mage/Core/etc/system.xml
patching file app/code/core/Mage/Customer/Model/Session.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Adapter/Zend/Cache.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php
patching file app/code/core/Mage/ImportExport/Model/Import/Uploader.php
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file app/code/core/Mage/Widget/Model/Widget/Instance.php
patching file app/code/core/Mage/XmlConnect/Helper/Image.php
patching file app/design/adminhtml/default/default/layout/main.xml
patching file app/design/adminhtml/default/default/template/notification/formkey.phtml
patching file app/design/adminhtml/default/default/template/notification/symlink.phtml
patching file app/design/adminhtml/default/default/template/page/head.phtml
patching file app/design/frontend/base/default/template/checkout/cart/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/billing.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/billing.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/payment.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml
patching file app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml
patching file app/etc/config.xml
patching file app/locale/en_US/Mage_Adminhtml.csv
patching file app/locale/en_US/Mage_Core.csv
patching file app/locale/en_US/Mage_Dataflow.csv
patching file downloader/Maged/Connect.php
patching file downloader/Maged/Controller.php
Hunk #1 succeeded at 400 (offset -5 lines).
Hunk #2 succeeded at 923 (offset -5 lines).
patching file downloader/Maged/Model/Session.php
Hunk #2 succeeded at 235 with fuzz 2 (offset -13 lines).
patching file js/varien/payment.js
patching file skin/frontend/base/default/js/opcheckout.js

even after applying older patches manually.

$ grep '|' app/etc/applied.patches.list
2017-06-19 04:01:42 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-19 04:03:26 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
2017-06-19 04:04:12 UTC | SUPEE-1049 | EE_1.12.0.2 | v1 | 5cd884653325315804056d4c591572385b3c1d03 | Thu Mar 20 16:33:19 2014 +0200 | v1.12.0.2..HEAD
2017-06-19 04:05:01 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-19 04:06:38 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-19 04:07:10 UTC | SUPEE-1533 | EE_1.12 | v1 | _ | n/a | SUPEE-1533_EE_1.12_v1.patch
2017-06-19 04:08:41 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-19 04:09:29 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-19 04:10:00 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-19 04:11:22 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-19 04:11:50 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-19 04:12:12 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-19 04:14:30 UTC | SUPEE-8167 | EE_1.12.0.2 | v1 | b1be28f9cd8c2ecba2aa403e59ad9e3d2855eb95 | Thu May 4 13:52:13 2017 +0300 | 8d12ea6fe564b6dc9ed1affb6de990f81aca3796..HEAD
2017-06-19 04:16:21 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-19 04:16:44 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
2017-06-19 04:19:35 UTC | SUPEE-6788 | CE_1.7.0.2 | v1 | 0398c4b951d9a0f64495e7b8b3b8ca480952dd70 | Fri Oct 23 13:50:23 2015 +0300 | cfc252b

The solution/problem I found is that some of the changes in the patch for 1.7.0.2 is for files that doesn't exist before 1.9.2.3. So I copied the following files from a brand new 1.9.2.3 installation before running the patch script:

app/code/core/Mage/Core/Model/File/Validator/Image.php
app/code/core/Mage/Sales/Model/Quote/Item.php

Jut an addition to https://magento.stackexchange.com/a/176930/46249

Note that Symlinks have always been disabled by default on new Magento installations admin YES/NO config values default to 'NO'. The update now explicitly disables symlinks in config.xml and as an extra precaution also removes the template section from admin->developer which contained the configuration option.

This will not affect your current symlink settings, if you manually enabled symlinks prior to 1.9.3.2 they will stay enabled, although you cannot see the setting anymore in admin.

The bold text isn't correct. If updating to 1.9.3.4 (SUPEE-9767 V2) or newer current settings will be deleted:

# app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.6-1.6.0.7.php
$connection->delete(
    $this->getTable('core_config_data'),
    $connection->prepareSqlCondition('path', array(
        'like' => 'dev/template/allow_symlink'
    ))
);

Responsible admins can enable the symlink admin section again by looking for the diff changes to the template section in app/code/core/Mage/Core/etc/system.xml and adding the section to your system.xml at around line 600. Or double check symlinks are still enabled with

Just make config option visible again does no solve the problem. The option shows up, but you're not able to change config since newly introduced backend model prevents saving the value. See:

# app/code/core/Mage/Core/etc/system.xml
<backend_model>adminhtml/system_config_backend_symlink</backend_model>

and

# Mage_Adminhtml_Model_System_Config_Backend_Symlink
public function save()
{
    return $this;
}

So you have to remove or override this backend model, see How to enable symlinks after SUPEE-9767 V2 install?

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 magento.stackexchange