Patch de segurança SUPEE-11086 - Possíveis problemas?

O Magento lançou um novo patch de segurança para o M1 e atualizações para o M1 e o M2.

Essas versões incluem correções críticas de segurança. "É altamente recomendável que todos os comerciantes atualizem o mais rápido possível."

Quais problemas devo procurar ao atualizar ou aplicar este patch?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 e Open Source 1.9.4.1 contêm vários aprimoramentos de segurança que ajudam a fechar a execução remota de código (RCE), scripts entre sites (XSS), falsificação de solicitação entre sites (CSRF) e outras vulnerabilidades.

Atualização de segurança Magento 2.3.1, 2.2.8 e 2.1.17

Essas versões contêm várias atualizações funcionais e de segurança. Risco: Crítico para o Magento Commerce e o Magento Open Source antes de 2.1.17, 2.2.8 e 2.3.1.

O maior problema encontrado: Mage::log()funciona incorretamente. Se você chamar essa função com um arquivo de log personalizado (e ainda não existir), o log não será gravado no arquivo, devido a uma validação adicional, adicionada no SUPEE-11086.

Importante: o nome do patch inclui a versão mais alta à qual o patch se aplica. Portanto, um patch para 1.9.3.10 se aplicaria a 1.9.3.10, 1.9.3.9, .... até outro patch. Vamos tentar melhorar a nomeação no próximo lançamento e você também pode usar https://github.com/steverobbins/magedownload-cli, pois ele deve ver os metadados das versões corretamente na API.

Como outros, eu tinha arquivos de log completamente parando de gravar dados.

Origem do erro - arquivos de log não gravam dados

Em app/Mage.phpfizeram essa mudança:

         // 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;
             }

que procura na configuração uma lista separada por vírgula de extensões de arquivos aprovadas. No entanto, eles NÃO adicionaram essa lista na configuração - nem mesmo uma opção no Mage Admin para nós configurarmos isso por conta própria.

Solução para o bug - arquivos de log não gravam dados

Para resolver isso, basta fazer uma entrada no banco de dados na core_config_datatabela.

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

Limpe o cache de objetos também e você deverá ver os dados gravando nos arquivos de log novamente.

ls -lrt var/log/ | tail

Para referência, esse problema estava no EE 1.14.2.0 com todos os patches de segurança aplicados.

Abri um ticket com o Suporte Magento sobre esse problema, mas ainda não recebi uma resposta de um técnico. Eu estou na fila.

O que realmente me confunde sobre esse bug é que o Magento já possui um método para validar extensões de arquivo de log que eles adicionaram via SUPEE-10415 no final de 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;
    }

Por que eles não reutilizaram essa lógica em vez de tentar uma reinvenção incompleta da roda de toras?

Mage::log()falha ao gravar qualquer coisa nos arquivos de log, se eles não existirem inicialmente. Isso ocorre devido à isValidfunção de Zend_Validate_File_Extensiongerar um erro não encontrado ao chamar Zend_Loader::isReadable($value). Corrigi isso temporariamente, movendo-me isValidpara a tentativa / captura depois que o arquivo de log é criado e removendo o arquivo se a validação falhar:

<?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;
                }

        ...
    }
}

Esta é definitivamente uma solução temporária até termos algo um pouco mais sólido

Possível problema com o patch 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

No patch, temos:

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();
         }
     }

no entanto, olhando para o código em 1.9.3.10 (via mage LTS), não vejo esse código em questão:

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

MAS, existe para 1.9.4

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

O possível motivo é um patch ausente não aplicado anteriormente.

Tentando instalar o patch no Magento 1.9.0.1 usando PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh Me deparei com este erro

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

Corrigi isso removendo o seguinte código de 'app / etc / config.xml' e executando o patch novamente

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

Também estou um pouco confuso sobre a nomeação dos patches M1.

Para patches mais antigos, eles os nomeavam como SUPEE-10975 for CE 1.9.3.4-1.9.3.10ou, SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB)mas agora estão apenas endereçando uma versão PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh.

O patch atual está abordando todas as versões de uma versão secundária ou apenas a última?

Eu fiz um teste com uma loja 1.9.3.1 e tudo passou, mas não tenho certeza se isso é preciso para outros lançamentos?

Quebra de logs no Magento 1.9. Para corrigir o log no patch SUPEE-11086:

No 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)) {

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

Eu espero que isso ajude!

Todos os novos arquivos PHP no patch para M1 têm vários modelos não processados

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

Não é um problema, mas parece impreciso. Eu tive o mesmo sentimento após o SUPEE-10975.

Percebi um problema com os arquivos de log que não estão mais sendo criados e somente sendo gravados se o arquivo de log já existir. Isso parece ser causado pela linha:

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

do app / Mage.php. Corrigi isso usando a lógica antiga. Portanto, substitua a linha acima pelo seguinte:

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

verificando arquivo app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php Hunk # 1 FAILED em 57. 1 em 1 hunk FAILED

No patch 10975, ocorreu um erro neste momento. A declaração de retorno estava ausente. Talvez você tenha corrigido esse bug após aplicar o patch 10975 ou ignorado a alteração. O bug foi corrigido em 11086. Se essa linha de código já tiver sido ajustada / ignorada por você, resultará no erro que você descreveu ao aplicar o novo patch. Se você já corrigiu o bug, remova o bloco no arquivo de patch e execute o patch novamente.

Usando SUPEE-11086 | CE_1.9.1.0, conforme sugerido por Ryan Hoerr acima.

Aplicando SUPEE-11086 | CE_1.9.1.0 v1 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Sexta, 22 de março de 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

Para CE_1.9.2.1

Eu recebo uma falha em cada arquivo.

Apliquei o patch com sucesso em outros repositórios.

Código principal intocado.

Lista de patches aplicados

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

Problemas com o patch M1.9.3.7 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

Pode confirmar que existe um problema ao tentar aplicar SUPEE-11086uma versão do 1.9.1.1 recém-baixada e totalmente corrigida, incluindo tudo, inclusive o Patch do Dashboard de gráficos do Admin -MPERF-10509-CE-2019-03-13-06-31-24.diff

O patch falha nos seguintes arquivos.

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

Esses arquivos não têm alterações desde o commit inicial do download da v1.9.1.1. A cópia de arquivos da instalação 1.9.2.4, a aplicação do SUPEE-11086 e a comparação com a fonte v1.9.4.1 confirma que agora eles correspondem.

Magento v1.9.1.1 parece ser um problema de criança ...

Pode confirmar que existe um problema ao tentar aplicar SUPEE-11086uma versão do 1.9.3.0 recém-baixada e totalmente corrigida, incluindo tudo, inclusive o Patch do Dashboard de gráficos do Admin -MPERF-10509-CE-2019-03-13-06-31-24.diff

O patch falha no app / config.xml, pois o nó abaixo está ausente. Inclua o nó antes de executar o SUPEE-11086, sem problemas.

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

Eu descobri um novo problema com o modelo Mage_Eav_Model_Attribute_Data_File

Na entidade clientes, adicionei atributos de upload de arquivo. Esses atributos não são necessários e, quando desejo excluir um arquivo sem fazer upload de um novo, a exclusão não está funcionando, porque o valor do atributo não é validado pelo novo métodosetAttributeValidationAsPassed()

A solução rápida que fiz está no método validateValue($value)

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

Esse problema parece estar presente em todas as versões do Magento 1.x desde SUPEE-11086

Magento 1.9.3.1

Ocorreu um problema ao tentar corrigir o CE 1.9.3.1 usando o 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