23

Magento has released a new security patch for M1, and updates for M1 and M2.

These releases include critical security fixes. "We strongly recommend that all merchants upgrade as soon as possible."

What issues should I look out for when upgrading or applying this patch?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 and Open Source 1.9.4.1 contain multiple security enhancements that help close remote code execution (RCE), cross-site scripting (XSS), cross-site request forgery (CSRF) and other vulnerabilities.

Magento 2.3.1, 2.2.8 and 2.1.17 Security Update

These versions contains multiple functional and security updates. Risk: Critical for Magento Commerce and Magento Open Source prior to 2.1.17, 2.2.8 and 2.3.1.

  • Ryan Hoerr,I guess that you have to create a different question for Magento 2.3.1, 2.2.8 and 2.1.17 Security Update – Amit Bera Mar 26 at 16:21
  • 2
    Any idea why there is no version for 1.8.0 / 1.8.1? – Jason Mar 27 at 6:03

17 Answers 17

21

The biggest problem, which was found: Mage::log() works incorrectly. If you call this function with custom log file (and it does not exist yet), log will not be written to the file, because of additional validation in the SUPEE-11086.

  • This issue also applies to Magento CE 1.9.4.1: magento.stackexchange.com/questions/268229/… – Aad Mathijssen Apr 1 at 19:16
  • 5
    all my logs stopped completely. Even System and exception logs. Is there a fix for this? – Kalvin Klien Apr 3 at 18:13
  • all my log files written to by Mage::log have stopped as well. M1 EE 1.14.0.2 – PromInc Apr 5 at 20:11
  • the only fix is to return back the code of Mage::log() – Aswerer Apr 6 at 23:18
10

Important: the patch name includes the highest version the patch applies to. So a patch for 1.9.3.10 would apply to 1.9.3.10, 1.9.3.9,.... down to another patch. We will try to improve naming in the next release and you can also use https://github.com/steverobbins/magedownload-cli as it should see the versions metadata properly over API.

5

Like others, I had log files completely stop writing data.

Source of the Bug - Log Files Not Writing Data

In app/Mage.php they made this change:

         // Validate file extension before save. Allowed file extensions: log, txt, html, csv
         -        if (!self::helper('log')->isLogFileExtensionValid($file)) {
         +        $_allowedFileExtensions = explode(
         +            ',',
         +            (string) self::getConfig()->getNode('dev/log/allowedFileExtensions', Mage_Core_Model_Store::DEFAULT_CODE)
         +        );
         +        $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);
         +        $logDir = self::getBaseDir('var') . DS . 'log';
         +        if (!$logValidator->isValid($logDir . DS . $file)) {
                 return;
             }

which is looking to the config for a comma separated list of approved file extensions. They did NOT add this list in the config however - not even an option in the Mage Admin for us to configure this on our own.

Solution to the Bug - Log Files Not Writing Data

To solve this, simply make an entry into the database in the core_config_data table.

INSERT INTO core_config_data VALUES ( NULL, 'default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv' );

Clear the objects cache as well and you should see data writing to the log files once again.

ls -lrt var/log/ | tail


For reference, this issue was on EE 1.14.2.0 with all security patches applied.

I did open a ticket with Magento Support on this issue but have not received a response from a technician yet. I'm in the queue.


What really confuses me about this bug is that Magento already has a method for validating log file extensions that they added via SUPEE-10415 in late 2017.

app/code/core/Mage/Log/Helper/Data.php

    /**
     * Checking if file extensions is allowed. If passed then return true.
     *
     * @param $file
     * @return bool
     */
    public function isLogFileExtensionValid($file)
    {
        $result = false;
        $validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);
        if ($validatedFileExtension && in_array($validatedFileExtension, $this->_allowedFileExtensions)) {
            $result = true;
        }

        return $result;
    }

Why didn't they reuse that logic instead of attempting an incomplete re-invention the log wheel?

  • 2
    This is not correct. In app/etc/config.xml the allowedFileExtensions has been added as configuration. If it doesn't exists in the database this will be used. The actual problem is that the new validation function first tries to see if the file already exists, which it might very wel not. – René Schep Apr 9 at 10:13
  • Thank you for pointing that out @RenéSchep I see that change in the patch now. Looking deeper, my config.xml file lives in a different repository as the rest of our code base. For that reason when I pushed the change for this patch the config file was not updated with this change. As for not writing to non-existent files, I'm personally finding that to work on my servers. Makes me wonder if this is a folder permissions issue on the file-system itself. I haven't looked too deep into that code however. – PromInc Apr 9 at 15:55
  • From what I've tested is that it works if the file already exists. The first check isValid does is check if the file is readable. If it doesn't exist there is no attempt to create the file and a false is returned. – René Schep Apr 10 at 10:41
4

Mage::log() fails to write anything to the log files if they do not exist initially. This is due to the isValid function of Zend_Validate_File_Extension throwing a not found error when calling Zend_Loader::isReadable($value). I have temporarily fixed this by moving isValid into the try/catch after the log file is actually created and then removing the file if the validation fails:

<?php
final class Mage
{
    ...
    public static function log($message, $level = null, $file = '', $forceLog = false)
    {
        ...

        try {
            if (!isset($loggers[$file])) {
                $logFile = $logDir . DS . $file;

                if (!is_dir($logDir)) {
                    mkdir($logDir);
                    chmod($logDir, 0750);
                }

                if (!file_exists($logFile)) {
                    file_put_contents($logFile, '');
                    chmod($logFile, 0640);
                }

                if (!$logValidator->isValid($logFile)) {
                    unlink($logFile);

                    return;
                }

        ...
    }
}

This is definitely a temporary solution until we have something a little more solid

3

Possible issue with patching 1.9.3.10

checking file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
Hunk #1 FAILED at 57.
1 out of 1 hunk FAILED

In the patch we have:

diff --git app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
index 8d3c526c280..fde2ef0d45d 100644
--- app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
+++ app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
@@ -57,7 +57,7 @@ class Mage_Adminhtml_Block_Customer_Group_Edit extends Mage_Adminhtml_Block_Widg
                 'form_key' => Mage::getSingleton('core/session')->getFormKey()
             ));
         } else {
-            parent::getDeleteUrl();
+            return parent::getDeleteUrl();
         }
     }

however, looking at the code on 1.9.3.10 (via mage LTS) I don't see that code in question:

https://github.com/OpenMage/magento-lts/blob/1.9.3.x/app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php

BUT, it does exist for 1.9.4

https://github.com/OpenMage/magento-lts/blob/1.9.4.x/app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php

Possible reason is a missing patch not previously applied.

  • 4
    You are missing the patch SUPEE-10975. – Richard Feraro Mar 27 at 4:10
  • mmm, according to my patch sets, that is applied already: 2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Thu Nov 8 13:45:47 2018 +0200 | ce-1.9.3.10-dev – ProxiBlue Mar 27 at 5:01
  • The filename of the latest patch is PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh while yours appears to be issued last Nov 8, 2018 which is not the latest I suppose. – Richard Feraro Mar 27 at 6:22
  • 1
    I reverted PATCH_SUPEE-10975 and re-applied, then re-applied latest, all worked – ProxiBlue Mar 27 at 7:50
  • This was a bug in SUPEE-10975 which caused you to not be able to delete Customer Groups. Looks like you fixed it manually, which causes this new patch to fail which is also fixing this. – René Schep Mar 27 at 9:13
3

Trying to install the patch on Magento 1.9.0.1 using PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh I came accross this error

Hunk #1 FAILED at 141.
1 out of 1 hunk FAILED

I fixed this by removing the following code from 'app/etc/config.xml' and then running the patch again

<dev>
    <template>
        <allow_symlink>0</allow_symlink>
    </template>
</dev>
3

I'm also a bit confused about the naming for the M1 patches.

For older patches they named them like SUPEE-10975 for CE 1.9.3.4-1.9.3.10 or SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB) but now it's only addressing one version PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh.

Is the current patch addressing all releases of a minor release or only the last one?

I made a test with a 1.9.3.1 store and everything went through but im not quite sure if that is accurate for other releases?

  • Thank you Ryan! Thats answers @jason question as well "Any idea why there is no version for 1.8.0 / 1.8.1?" For that he should go with the 1.7.0.2 Patch, right? Didn't know that there were patches addressing multiple minor releases before. – Sebastian Mar 27 at 12:32
  • 2
    you sure @RyanHoerr? Is it not the opposite, as it is presumed on another thread magento.stackexchange.com/questions/267576/…? It seems that, if we guess from the old naming style, PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh could be applied from 1.7.0.0 to 1.7.0.2, and so, the version number in each patch would be the last in that case. Anyone from Magento could confirm what is the logic behind that new naming style please? Thx in advance.. – Antoine Kociuba Mar 28 at 0:29
  • 2
    I'll go with @AntoineKociuba With 2 different 1.8.1 stores i run into 4 fails with the 1.7.0.2 Patch: - app/code/core/Mage/Usa/etc/system.xml Hunk #4 FAILED at 845 - app/etc/config.xml Hunk #1 FAILED at 144 - app/locale/en_US/Mage_Widget.csv Hunk #1 FAILED at 6 - lib/Varien/Filter/Template.php Hunk #2 FAILED at 254 whereas the 1.9.1.0 runs smoothly. Same with a 1.9.3.1 store: The patch 1.9.2.4 doenst work whereas the 1.9.3.10 does. – Sebastian Mar 28 at 9:00
  • 3
    @RyanHoerr this is incorrect. The name includes the latest version a patch applies to. So a patch for 1.9.3.10 would apply to 1.9.3.10, 1.9.3.9,.... down to another patch. We will try to improve naming in the next release and you can also use github.com/steverobbins/magedownload-cli as it should see the versions metadata properly over API. – Piotr Kaminski Mar 28 at 15:20
  • Removed my bad info. Thanks for the correction. – Ryan Hoerr Mar 28 at 15:56
2

Logging breaks in Magento 1.9. To fix logging in the SUPEE-11086 patch:

In app/Mage.php:

-        $logValidator = new Zend_Validate_File_Extension($_allowedFileExtensions);
         $logDir = self::getBaseDir('var') . DS . 'log';
-        if (!$logValidator->isValid($logDir . DS . $file)) {
+        $validatedFileExtension = pathinfo($file, PATHINFO_EXTENSION);
+        if (!$validatedFileExtension || !in_array($validatedFileExtension, $_allowedFileExtensions)) {

Resource: https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

  • This patch also broke Neklo Security 1.2.1 MFA (still investigating)

I hope this helps!

1

All new PHP files in the patch for M1 have non-processed template vars

<?php
/**
 * {license_notice}
 *
 * @copyright   {copyright}
 * @license     {license_link}
 */

Not an issue but looks inaccurate. I had the same feeling after SUPEE-10975.

1

I've noticed an issue with log files no longer being created and only being written out if the log file already exists. This looks to be caused by the line:

if (!$logValidator->isValid($logDir . DS . $file)) {

from app/Mage.php. I fixed this by using the old logic. So replace the line above with the following:

if (!self::helper('log')->isLogFileExtensionValid($file)) {
0

checking file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php Hunk #1 FAILED at 57. 1 out of 1 hunk FAILED

In patch 10975 there was an error at this point. The return statement was missing. Maybe you fixed this bug after applying patch 10975 or ignored the change. The bug was fixed in 11086. If this line of code has already been adjusted / ignored by you, it will result in the error you described when applying the new patch. If you have already fixed the bug yourself, then just remove the block in the patch file and run the patch again.

0

Using SUPEE-11086 | CE_1.9.1.0 as suggested by Ryan Hoerr above.

Applying SUPEE-11086 | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Fri Mar 22 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

To CE_1.9.2.1

I get a Fail on each file.

I have successfully applied the patch to other repos.

Core code untouched.

List of patches applied

SUPEE-6788
SUPEE-7405-CE-1-9-2-2
SUPEE-7405 
SUPEE-8788 
SUPEE-9652 
SUPEE-8967 
PATCH_SUPEE-9767_CE_1.9.3.0_v2
SUPEE-10266-CE-1.9.2.4
SUPEE-10415-ce-1.9.2.1
SUPEE-10570_CE_v1.9.2.2
SUPEE-10570_CE_v1.9.2.2
SUPEE-10570_CE_v1.9.2.2
SUPEE-10752_CE_v1.9.2.4
SUPEE-10888_CE_v1.9.2.4
SUPEE-10975_CE_v1.9.3.3
  • Thanks @AntoineKociuba for the clarification. I have verified that the previous patches have all been correct, but when I apply the correct patch as stated below PATCH_SUPEE-11086_CE_1.9.2.4_v1 for my 1.9.2.1 installation, I am still getting an error on all but one hunk. Would you suggest a manual patch? – Bevan Holman Mar 29 at 0:24
  • Which hunk are you failing on? – René Schep Mar 29 at 14:43
  • This has been resolved, I had to get a new clone of the repo. Thanks René – Bevan Holman Apr 1 at 3:12
0

Issues with M1.9.3.7 Patch PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh

checking file app/Mage.php
checking file app/code/core/Mage/Admin/Model/Session.php
checking file app/code/core/Mage/Adminhtml/Block/Api/Buttons.php
checking file app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit.php
checking file app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php
Hunk #1 FAILED at 57.
1 out of 1 hunk FAILED
checking file app/code/core/Mage/Adminhtml/Block/Permissions/Buttons.php
checking file app/code/core/Mage/Adminhtml/Block/System/Design/Edit.php
checking file app/code/core/Mage/Adminhtml/Block/System/Store/Edit.php
checking file app/code/core/Mage/Adminhtml/Controller/Action.php
checking file app/code/core/Mage/Adminhtml/Helper/Data.php
checking file app/code/core/Mage/Adminhtml/Model/Email/PathValidator.php
checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED
  • Seeing as app/code/core/Mage/Adminhtml/Block/Customer/Group/Edit.php failed. I assume you applied patch SUPEE-11043 which SUPEE-11086 assumes you haven't done. – René Schep Apr 1 at 7:43
0

Can confirm an issue exists when attempting to apply SUPEE-11086 on a newly downloaded and fully patched version of 1.9.1.1, including everything up to and including Admin Dashboard Charts Patch - MPERF-10509-CE-2019-03-13-06-31-24.diff

Patch fails in the following files.

app/code/core/Mage/Adminhtml/Block/Api/Buttons.php
app/code/core/Mage/Adminhtml/Block/Permissions/Buttons.php
app/code/core/Mage/Api2/Block/Adminhtml/Roles/Buttons.php

These files have no changes from the initial commit of v1.9.1.1 download. Copying files from 1.9.2.4 install, applying SUPEE-11086 and then comparing with v1.9.4.1 source confirms they now match.

Magento v1.9.1.1 does seem to be a bit of a problem child...

  • I just compared the 1.9.2.4 patch with the 1.9.1.0 patch. And it looks like difference between these patches are the 3 files you mention. So it looks like the 1.9.1.0 patch should be used on 1.9.1.1. – René Schep Apr 18 at 9:01
0

Can confirm an issue exists when attempting to apply SUPEE-11086 on a newly downloaded and fully patched version of 1.9.3.0, including everything up to and including Admin Dashboard Charts Patch - MPERF-10509-CE-2019-03-13-06-31-24.diff

Patch fails in app/config.xml as node below is missing. Add node prior to running SUPEE-11086, no problems.

<config>
    </default>
        <dev>
            <template>
                <allow_symlink>0</allow_symlink>
            </template>
        </dev>
    </default>
</config>
0

I discovered a new issue with the model Mage_Eav_Model_Attribute_Data_File

On the customers entity, I've added file upload attributes. These attributes are not required, and when I want to delete a file without uploading a new one, the deletion is not working , because the attribute value is not validated via the new method setAttributeValidationAsPassed()

The quick fix i've done is in the method validateValue($value)

if (!$attribute->getIsRequired() && !$toUpload) {
    $attribute->setAttributeValidationAsPassed(); // this new line is added 
    return true;
}

This problem seems to be present in all Magento 1.x releases since SUPEE-11086

0

Magento 1.9.3.1

Issue occurred when trying to patch CE 1.9.3.1 using patch PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh:

checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED

protected by Community Apr 17 at 15:15

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.