Patch de sécurité SUPEE-11086 - Problèmes possibles?

Magento a publié un nouveau correctif de sécurité pour M1 et des mises à jour pour M1 et M2.

Ces versions incluent des correctifs de sécurité critiques. "Nous recommandons fortement à tous les marchands d'effectuer une mise à niveau dès que possible."

Quels problèmes dois-je rechercher lors de la mise à niveau ou de l'application de ce correctif?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 et Open Source 1.9.4.1 contiennent plusieurs améliorations de sécurité qui aident à fermer l'exécution de code à distance (RCE), les scripts intersites (XSS), la falsification de requêtes intersites (CSRF) et d'autres vulnérabilités.

Mise à jour de sécurité pour Magento 2.3.1, 2.2.8 et 2.1.17

Ces versions contiennent plusieurs mises à jour fonctionnelles et de sécurité. Risque: critique pour Magento Commerce et Magento Open Source avant 2.1.17, 2.2.8 et 2.3.1.

Le plus gros problème, qui a été trouvé: ne Mage::log()fonctionne pas correctement. Si vous appelez cette fonction avec un fichier journal personnalisé (et qu'il n'existe pas encore), le journal ne sera pas écrit dans le fichier, en raison d'une validation supplémentaire, ajoutée dans le SUPEE-11086.

Important: le nom du patch inclut la version la plus élevée à laquelle le patch s'applique. Ainsi, un patch pour 1.9.3.10 s'appliquerait à 1.9.3.10, 1.9.3.9, .... jusqu'à un autre patch. Nous allons essayer d'améliorer la dénomination dans la prochaine version et vous pouvez également utiliser https://github.com/steverobbins/magedownload-cli car il devrait voir les métadonnées des versions correctement sur l'API.

Comme d'autres, j'avais des fichiers journaux qui arrêtaient complètement d'écrire des données.

Source du bogue - Les fichiers journaux n'écrivent pas de données

Dans app/Mage.phpils ont fait ce changement:

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

qui cherche dans la configuration une liste séparée par des virgules d'extensions de fichiers approuvées. Cependant, ils n'ont pas ajouté cette liste dans la configuration - pas même une option dans l'administrateur Mage pour que nous puissions la configurer nous-mêmes.

Solution au bogue - les fichiers journaux n'écrivent pas de données

Pour résoudre ce problème, entrez simplement une entrée dans la base de données dans le core_config_datatableau.

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

Videz également le cache des objets et vous devriez voir de nouveau l'écriture de données dans les fichiers journaux.

ls -lrt var/log/ | tail

Pour référence, ce problème était sur EE 1.14.2.0 avec tous les correctifs de sécurité appliqués.

J'ai ouvert un ticket avec le support Magento sur ce problème mais je n'ai pas encore reçu de réponse d'un technicien. Je suis dans la file d'attente.

Ce qui me dérange vraiment à propos de ce bogue, c'est que Magento a déjà une méthode pour valider les extensions de fichier journal qu'ils ont ajoutées via SUPEE-10415 fin 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;
    }

Pourquoi n'ont-ils pas réutilisé cette logique au lieu de tenter une réinvention incomplète de la roue à grumes?

Mage::log()ne parvient pas à écrire quoi que ce soit dans les fichiers journaux s'ils n'existent pas initialement. Cela est dû à la isValidfonction de Zend_Validate_File_Extensionlancement d'une erreur introuvable lors de l'appel Zend_Loader::isReadable($value). J'ai temporairement résolu ce problème isValiden accédant à la tentative / capture une fois le fichier journal créé et en supprimant le fichier si la validation échoue:

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

        ...
    }
}

Ceci est définitivement une solution temporaire jusqu'à ce que nous ayons quelque chose d'un peu plus solide

Problème possible avec le correctif 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

Dans le patch, nous avons:

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

cependant, en regardant le code sur 1.9.3.10 (via mage LTS), je ne vois pas ce code en question:

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

MAIS, il existe pour 1.9.4

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

La raison possible est un patch manquant non appliqué précédemment.

Essayer d'installer le correctif sur Magento 1.9.0.1 en utilisant PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh Je suis tombé sur cette erreur

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

J'ai corrigé cela en supprimant le code suivant de 'app / etc / config.xml' puis en exécutant à nouveau le patch

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

Je suis également un peu confus quant à la dénomination des correctifs M1.

Pour les anciens correctifs, ils les ont nommés comme 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)mais maintenant, cela ne concerne qu'une seule versionPATCH_SUPEE-11086_CE_1.9.3.10_v1.sh .

Le correctif actuel concerne-t-il toutes les versions d'une version mineure ou uniquement la dernière?

J'ai fait un test avec un magasin 1.9.3.1 et tout s'est passé mais je ne sais pas trop si c'est exact pour les autres versions?

Journalisation des pauses dans Magento 1.9. Pour corriger la journalisation dans le correctif SUPEE-11086:

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

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

J'espère que ça aide!

Tous les nouveaux fichiers PHP du patch pour M1 ont des vars de modèles non traités

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

Pas un problème mais semble inexact. J'ai eu le même sentiment après SUPEE-10975.

J'ai remarqué un problème avec les fichiers journaux qui ne sont plus créés et qui ne sont écrits que si le fichier journal existe déjà. Cela semble être causé par la ligne:

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

depuis app / Mage.php. J'ai corrigé cela en utilisant l'ancienne logique. Remplacez donc la ligne ci-dessus par ce qui suit:

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

vérification du fichier app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php Hunk # 1 FAILED at 57. 1 sur 1 hunk FAILED

Dans le patch 10975, il y avait une erreur à ce stade. La déclaration de retour était manquante. Vous avez peut-être corrigé ce bogue après avoir appliqué le patch 10975 ou ignoré la modification. Le bogue a été corrigé dans 11086. Si cette ligne de code a déjà été ajustée / ignorée par vous, cela entraînera l'erreur que vous avez décrite lors de l'application du nouveau correctif. Si vous avez déjà corrigé le bogue vous-même, supprimez simplement le bloc dans le fichier de correctif et réexécutez le correctif.

Utilisation de SUPEE-11086 | CE_1.9.1.0 comme suggéré par Ryan Hoerr ci-dessus.

Application de SUPEE-11086 | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Ven.22 mars 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

À CE_1.9.2.1

J'obtiens un échec sur chaque fichier.

J'ai appliqué avec succès le correctif à d'autres dépôts.

Code de base intact.

Liste des patchs appliqués

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

Problèmes avec le 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

Peut confirmer qu'un problème existe lors de la tentative d'application SUPEE-11086sur une version nouvellement téléchargée et entièrement corrigée de 1.9.1.1, y compris tout ce qui va jusqu'à et y compris le correctif Admin Dashboard Charts Patch -MPERF-10509-CE-2019-03-13-06-31-24.diff

Le patch échoue dans les fichiers suivants.

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

Ces fichiers n'ont aucune modification depuis la validation initiale du téléchargement de la version 1.9.1.1. La copie des fichiers à partir de l'installation de 1.9.2.4, l'application de SUPEE-11086, puis la comparaison avec la source v1.9.4.1 confirme qu'ils correspondent maintenant.

Magento v1.9.1.1 semble être un peu un problème enfant ...

Peut confirmer qu'un problème existe lors de la tentative d'application SUPEE-11086sur une version nouvellement téléchargée et entièrement corrigée de 1.9.3.0, y compris tout ce qui va jusqu'à et y compris le correctif Admin Dashboard Charts Patch -MPERF-10509-CE-2019-03-13-06-31-24.diff

Le correctif échoue dans app / config.xml car le nœud ci-dessous est manquant. Ajoutez un nœud avant d'exécuter SUPEE-11086, aucun problème.

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

J'ai découvert un nouveau problème avec le modèle Mage_Eav_Model_Attribute_Data_File

Sur l'entité clients, j'ai ajouté des attributs de téléchargement de fichiers. Ces attributs ne sont pas obligatoires et lorsque je souhaite supprimer un fichier sans en télécharger un nouveau, la suppression ne fonctionne pas, car la valeur de l'attribut n'est pas validée via la nouvelle méthodesetAttributeValidationAsPassed()

La solution rapide que j'ai faite est dans la méthode validateValue($value)

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

Ce problème semble être présent dans toutes les versions de Magento 1.x depuis SUPEE-11086

Magento 1.9.3.1

Un problème est survenu lors de la tentative de correction de CE 1.9.3.1 à l'aide du correctif 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