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


24

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.


Ryan Hoerr, je suppose que vous devez créer une question différente pour Magento 2.3.1, 2.2.8 et 2.1.17 Mise à jour de sécurité
Amit Bera

2
Une idée pourquoi il n'y a pas de version pour 1.8.0 / 1.8.1?
Jason

Réponses:


20

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.


Ce problème s'applique également à Magento CE 1.9.4.1: magento.stackexchange.com/questions/268229/…
Aad Mathijssen

5
tous mes journaux se sont complètement arrêtés. Même les journaux système et d'exception. Y a-t-il une solution à cela?
Kalvin Klien

tous mes fichiers journaux écrits par Mage :: log se sont également arrêtés. M1 EE 1.14.0.2
PromInc

la seule solution est de retourner le code deMage::log()
Aswerer

3
Depuis le 25 juin, Magento a publié SUPEE-11155, Magento Commerce 1.14.4.2 et Magento Open Source 1.9.4.2 qui incluent un correctif pour la Mage::log()méthode.
Aad Mathijssen

11

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.


5

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?


3
Ce n'est pas correct. Dans app / etc / config.xml, la permissionFileExtensions a été ajoutée en tant que configuration. S'il n'existe pas dans la base de données, il sera utilisé. Le problème réel est que la nouvelle fonction de validation essaie d'abord de voir si le fichier existe déjà, ce qui pourrait très bien ne pas être le cas.
René Schep

Merci d'avoir souligné cela @ RenéSchep Je vois ce changement dans le patch maintenant. En regardant plus loin, mon fichier config.xml réside dans un référentiel différent du reste de notre base de code. Pour cette raison, lorsque j'ai poussé la modification de ce correctif, le fichier de configuration n'a pas été mis à jour avec cette modification. Quant à ne pas écrire sur des fichiers inexistants, je trouve personnellement que cela fonctionne sur mes serveurs. Me fait me demander s'il s'agit d'un problème d'autorisations de dossier sur le système de fichiers lui-même. Cependant, je n'ai pas trop approfondi ce code.
PromInc

D'après ce que j'ai testé, cela fonctionne si le fichier existe déjà. La première vérification effectuée par isValid consiste à vérifier si le fichier est lisible. S'il n'existe pas, aucune tentative de création de fichier n'est effectuée et un faux est renvoyé.
René Schep

@ RenéSchep alors comment y remédier? Le support de Magento est douloureux dans le a ** h. Ils sont très lents à répondre.
Adarsh ​​Khatri

@AdarshKhatri vous devez créer le fichier avant que Magento puisse y écrire. touch /path/to/magento/install/html/var/log/newlogfile.log
PromInc

4

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


3

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.


4
Il vous manque le patch SUPEE-10975.
Richard Feraro

mmm, selon mes jeux de patchs, qui est déjà appliqué: 29/12/2018 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Jeu 8 nov 13:45:47 2018 +0200 | ce-1.9.3.10-dev
ProxiBlue

Le nom de fichier du dernier correctif est PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh tandis que le vôtre semble avoir été publié le 8 novembre 2018, ce qui n'est pas le dernier, je suppose.
Richard Feraro

1
J'ai rétabli PATCH_SUPEE-10975 et réappliqué, puis
réappliqué le

Il s'agissait d'un bogue dans SUPEE-10975 qui vous empêchait de supprimer des groupes de clients. Il semble que vous l'ayez corrigé manuellement, ce qui entraîne l'échec de ce nouveau correctif, ce qui résout également ce problème.
René Schep

3

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>

3

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?


Merci Ryan! Cela répond également à la question @jason "Une idée pourquoi il n'y a pas de version pour 1.8.0 / 1.8.1?" Pour cela, il devrait aller avec le patch 1.7.0.2, non? Je ne savais pas qu'il y avait des correctifs pour plusieurs versions mineures auparavant.
Sebastian

2
vous êtes sûr @RyanHoerr? N'est-ce pas le contraire, comme on le suppose sur un autre thread magento.stackexchange.com/questions/267576/… ? Il semble que, si nous supposons à partir de l'ancien style de nommage, PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh pourrait être appliqué de 1.7.0.0 à 1.7.0.2, et donc, le le numéro de version dans chaque patch serait le dernier dans ce cas. N'importe qui de Magento pourrait confirmer quelle est la logique derrière ce nouveau style de nommage, s'il vous plaît? Thx à l'avance ..
Antoine Kociuba

2
J'irai avec @AntoineKociuba Avec 2 magasins 1.8.1 différents que j'exécute en 4 échoue avec le patch 1.7.0.2: - app / code / core / Mage / Usa / etc / system.xml Hunk # 4 FAILED at 845 - app /etc/config.xml Hunk # 1 FAILED à 144 - app / locale / en_US / Mage_Widget.csv Hunk # 1 FAILED à 6 - lib / Varien / Filter / Template.php Hunk # 2 FAILED à 254 alors que le 1.9.1.0 s'exécute doucement. Même chose avec un magasin 1.9.3.1: le patch 1.9.2.4 ne fonctionne pas, contrairement au 1.9.3.10.
Sebastian

3
@RyanHoerr c'est incorrect. Le nom inclut la dernière version à laquelle un 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 le nommage dans la prochaine version et vous pouvez également utiliser github.com/steverobbins/magedownload-cli car il devrait voir les métadonnées des versions correctement sur l'API.
Piotr Kaminski

Suppression de mes mauvaises informations. Merci pour la correction.
Ryan Hoerr

2

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!


1

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.


1

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

0

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.


1
J'ai dû annuler le patch "moins officiel" SUPEE-11043 pour que SUPEE-11086 fonctionne
Jeroen Vermeulen - MageHost

0

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

Merci @AntoineKociuba pour la clarification. J'ai vérifié que les correctifs précédents ont tous été corrects, mais lorsque j'applique le correct correct comme indiqué ci-dessous PATCH_SUPEE-11086_CE_1.9.2.4_v1 pour mon installation 1.9.2.1, je reçois toujours une erreur sur tous les morceaux sauf un. Souhaitez-vous suggérer un patch manuel?
Bevan Holman

Sur quel morceau échouez-vous?
René Schep

Cela a été résolu, j'ai dû obtenir un nouveau clone du dépôt. Merci René
Bevan Holman

0

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

Échec de la recherche en tant qu'application / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php. Je suppose que vous avez appliqué le patch SUPEE-11043 que SUPEE-11086 suppose que vous n'avez pas fait.
René Schep

0

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 ...


Je viens de comparer le patch 1.9.2.4 avec le patch 1.9.1.0. Et il semble que la différence entre ces correctifs soit les 3 fichiers que vous mentionnez. Il semble donc que le patch 1.9.1.0 devrait être utilisé sur 1.9.1.1.
René Schep

0

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>

0

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


0

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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.