Patch di sicurezza SUPEE-11086 - Possibili problemi?


24

Magento ha rilasciato una nuova patch di sicurezza per M1 e aggiornamenti per M1 e M2.

Queste versioni includono correzioni di sicurezza critiche. "Raccomandiamo vivamente che tutti i commercianti eseguano l'upgrade il prima possibile."

Quali problemi dovrei cercare durante l'aggiornamento o l'applicazione di questa patch?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 e Open Source 1.9.4.1 contengono numerosi miglioramenti della sicurezza che aiutano a chiudere l'esecuzione di codice in remoto (RCE), lo scripting tra siti (XSS), la falsificazione di richieste tra siti (CSRF) e altre vulnerabilità.

Aggiornamento di sicurezza Magento 2.3.1, 2.2.8 e 2.1.17

Queste versioni contengono più aggiornamenti funzionali e di sicurezza. Rischio: critico per Magento Commerce e Magento Open Source precedenti a 2.1.17, 2.2.8 e 2.3.1.


Ryan Hoerr, immagino che devi creare una domanda diversa per Magento 2.3.1, 2.2.8 e 2.1.17 Aggiornamento di sicurezza
Amit Bera

2
Hai idea del perché non esiste una versione per 1.8.0 / 1.8.1?
Jason il

Risposte:


20

Il problema più grande, che è stato riscontrato: Mage::log()funziona in modo errato. Se si chiama questa funzione con un file di registro personalizzato (e non esiste ancora), il registro non verrà scritto nel file, a causa di un'ulteriore convalida, aggiunto nel SUPEE-11086.


Questo problema si applica anche a Magento CE 1.9.4.1: magento.stackexchange.com/questions/268229/…
Aad Mathijssen

5
tutti i miei registri si sono fermati completamente. Anche i registri di sistema e delle eccezioni. C'è una correzione per questo?
Kalvin Klien,

anche tutti i miei file di registro scritti da Mage :: log si sono fermati. M1 EE 1.14.0.2
PromInc

l'unica soluzione è restituire il codice diMage::log()
Aswerer

3
A partire dal 25 giugno, Magento ha rilasciato SUPEE-11155, Magento Commerce 1.14.4.2 e Magento Open Source 1.9.4.2 che includono una correzione per il Mage::log()metodo.
Aad Mathijssen,

11

Importante: il nome della patch include la versione più alta a cui si applica la patch. Quindi una patch per 1.9.3.10 si applicherebbe a 1.9.3.10, 1.9.3.9, .... fino a un'altra patch. Cercheremo di migliorare la denominazione nella prossima versione e puoi anche usare https://github.com/steverobbins/magedownload-cli in quanto dovrebbe visualizzare correttamente i metadati delle versioni sull'API.


5

Come altri, ho avuto completamente smettere di scrivere i dati dei file di registro.

Origine del bug: i file di registro non scrivono dati

In app/Mage.phphanno fatto questo cambiamento:

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

che sta cercando la configurazione per un elenco separato da virgole di estensioni di file approvate. Tuttavia NON hanno aggiunto questo elenco nella configurazione, nemmeno un'opzione nell'amministratore Mage per noi per configurarlo da soli.

Soluzione al bug - File di registro che non scrivono dati

Per risolvere questo, è sufficiente inserire una voce nel database nella core_config_datatabella.

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

Svuota anche la cache degli oggetti e dovresti visualizzare nuovamente i dati che scrivono nei file di registro.

ls -lrt var/log/ | tail


Per riferimento, questo problema riguardava EE 1.14.2.0 con tutte le patch di sicurezza applicate.

Ho aperto un ticket con il supporto Magento su questo problema ma non ho ancora ricevuto risposta da un tecnico. Sono in coda.


Ciò che mi confonde di questo bug è che Magento ha già un metodo per convalidare le estensioni dei file di registro che hanno aggiunto tramite SUPEE-10415 alla fine del 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;
    }

Perché non hanno riutilizzato quella logica invece di tentare una reinvenzione incompleta della ruota del ceppo?


3
Questo non è corretto In app / etc / config.xml è stato aggiunto permessoFileExtensions come configurazione. Se non esiste nel database, verrà utilizzato. Il vero problema è che la nuova funzione di validazione cerca prima di vedere se il file esiste già, cosa che potrebbe benissimo non essere.
René Schep,

Grazie per averlo sottolineato @ RenéSchep Ora vedo quel cambiamento nella patch. Guardando più in profondità, il mio file config.xml vive in un repository diverso come il resto della nostra base di codice. Per tale motivo, quando ho inviato la modifica per questa patch, il file di configurazione non è stato aggiornato con questa modifica. Per quanto riguarda la non scrittura su file inesistenti, trovo personalmente che funzioni sui miei server. Mi chiedo se si tratta di un problema con le autorizzazioni delle cartelle sul file system stesso. Non ho analizzato troppo a fondo questo codice.
PromInc

Da quello che ho testato è che funziona se il file esiste già. Il primo controllo che isValid non verifica è se il file è leggibile. Se non esiste, non esiste alcun tentativo di creare il file e viene restituito un falso.
René Schep,

@ RenéSchep, quindi come possiamo risolverlo? Il supporto di Magento è dolore nell'a ** h. Sono molto lenti a rispondere.
Adarsh ​​Khatri,

@AdarshKhatri devi creare il file prima che Magento possa scrivergli. touch /path/to/magento/install/html/var/log/newlogfile.log
PromInc

4

Mage::log()non riesce a scrivere nulla nei file di registro se non esistono inizialmente. Ciò è dovuto alla isValidfunzione di Zend_Validate_File_Extensiongenerare un errore non trovato durante la chiamata Zend_Loader::isReadable($value). Ho risolto temporaneamente questo problema spostandomi isValidin try / catch dopo che il file di registro è stato effettivamente creato e quindi rimuovendo il file se la convalida fallisce:

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

        ...
    }
}

Questa è sicuramente una soluzione temporanea fino a quando non avremo qualcosa di più solido


3

Possibile problema con la 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

Nella patch abbiamo:

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

tuttavia, guardando il codice in 1.9.3.10 (tramite il mago LTS) non vedo quel codice in questione:

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

MA, esiste per 1.9.4

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

Il motivo possibile è una patch mancante non precedentemente applicata.


4
Manca la patch SUPEE-10975.
Richard Feraro,

mmm, secondo i miei set di patch, che è già applicato: 29-12-2018 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Gio 8 Nov 13:45:47 2018 +0200 | ce-1.9.3.10-dev
ProxiBlue

Il nome file dell'ultima patch è PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh mentre il tuo sembra essere stato rilasciato lo scorso 8 novembre 2018, che non è l'ultimo suppongo.
Richard Feraro,

1
Ho ripristinato PATCH_SUPEE-10975 e riapplicato, quindi riapplicato per ultimo, tutto ha funzionato
ProxiBlue

Si è verificato un errore in SUPEE-10975 che non ha consentito di eliminare i gruppi di clienti. Sembra che tu l'abbia corretto manualmente, il che causa il fallimento di questa nuova patch, che sta anche risolvendo questo problema.
René Schep,

3

Tentativo di installare la patch su Magento 1.9.0.1 utilizzando PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh Ho riscontrato questo errore

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

Ho risolto questo problema rimuovendo il seguente codice da 'app / etc / config.xml' e quindi eseguendo nuovamente la patch

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

3

Sono anche un po 'confuso riguardo alla denominazione delle patch M1.

Per le patch più vecchie le hanno chiamate come SUPEE-10975 for CE 1.9.3.4-1.9.3.10o SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB)ma ora si rivolge solo a una versione PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh.

La patch attuale riguarda tutte le versioni di una versione minore o solo l'ultima?

Ho fatto un test con un negozio 1.9.3.1 e tutto è andato a buon fine ma non sono del tutto sicuro che sia accurato per altre versioni?


Grazie Ryan! Ecco la risposta alla domanda di @jason "Hai idea del perché non esiste una versione per 1.8.0 / 1.8.1?" Per questo dovrebbe andare con la patch 1.7.0.2, giusto? Non sapevo che prima c'erano patch per più versioni minori.
Sebastian

2
sei sicuro @RyanHoerr? Non è il contrario, come si presume su un altro thread magento.stackexchange.com/questions/267576/… ? Sembra che, se indoviniamo dal vecchio stile di denominazione, PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh potrebbe essere applicato dall'1.7.0.0 all'1.7.0.2, e così, il il numero di versione in ogni patch sarebbe l' ultimo in quel caso. Qualcuno di Magento potrebbe confermare qual è la logica dietro quel nuovo stile di denominazione, per favore? Grazie in anticipo ..
Antoine Kociuba

2
Andrò con @AntoineKociuba Con 2 diversi negozi 1.8.1 che incontro 4 falliscono con la 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 a 144 - app / locale / en_US / Mage_Widget.csv Hunk # 1 FAILED a 6 - lib / Varien / Filter / Template.php Hunk # 2 FAILED a 254 mentre l'1.9.1.0 viene eseguito senza intoppi. Lo stesso con un negozio 1.9.3.1: la patch 1.9.2.4 non funziona mentre la 1.9.3.10 funziona.
Sebastian

3
@RyanHoerr questo non è corretto. Il nome include l'ultima versione a cui si applica una patch. Quindi una patch per 1.9.3.10 si applicherebbe a 1.9.3.10, 1.9.3.9, .... fino a un'altra patch. Cercheremo di migliorare la denominazione nella prossima versione e puoi anche usare github.com/steverobbins/magedownload-cli in quanto dovrebbe visualizzare correttamente i metadati delle versioni sull'API.
Piotr Kaminski,

Rimosse le mie informazioni sbagliate. Grazie per la correzione.
Ryan Hoerr,

2

Interruzioni della registrazione in Magento 1.9. Per correggere la registrazione nella patch SUPEE-11086:

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

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

Spero che aiuti!


1

Tutti i nuovi file PHP nella patch per M1 hanno varianti di modello non elaborate

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

Non è un problema ma sembra impreciso. Ho avuto la stessa sensazione dopo SUPEE-10975.


1

Ho notato un problema con i file di registro non più creati e scritti solo se il file di registro esiste già. Questo sembra essere causato dalla linea:

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

dall'app / Mage.php. Ho risolto questo problema usando la vecchia logica. Quindi sostituisci la riga sopra con la seguente:

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

0

controllo app file / codice / core / Mage / Adminhtml / Block / Customer / Group / Edit.php Hunk # 1 FALLITO a 57. 1 hunk su 1 FAILED

Nella patch 10975 si è verificato un errore a questo punto. Mancava la dichiarazione di reso. Forse hai corretto questo errore dopo aver applicato la patch 10975 o ignorato la modifica. Il bug è stato corretto nel 11086. Se questa riga di codice è già stata modificata / ignorata da te, si verificherà l'errore che hai descritto durante l'applicazione della nuova patch. Se hai già corretto il bug da solo, rimuovi semplicemente il blocco nel file patch ed esegui nuovamente la patch.


1
Ho dovuto ripristinare la patch "meno ufficiale" SUPEE-11043 affinché SUPEE-11086 funzioni
Jeroen Vermeulen - MageHost

0

Utilizzo di SUPEE-11086 | CE_1.9.1.0 come suggerito da Ryan Hoerr sopra.

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

A CE_1.9.2.1

Ottengo un errore su ogni file.

Ho applicato con successo la patch ad altri repository.

Codice core intatto.

Elenco di patch applicate

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

Grazie @AntoineKociuba per il chiarimento. Ho verificato che le patch precedenti erano tutte corrette, ma quando applico la patch corretta come indicato di seguito PATCH_SUPEE-11086_CE_1.9.2.4_v1 per la mia installazione 1.9.2.1, sto ancora ricevendo un errore su tutti tranne uno. Consiglieresti una patch manuale?
Bevan Holman

In quale pezzo stai fallendo?
René Schep,

Questo è stato risolto, ho dovuto ottenere un nuovo clone del repository. Grazie René
Bevan Holman

0

Problemi con la 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

Visto che app / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php non sono riusciti. Suppongo che tu abbia applicato la patch SUPEE-11043 che SUPEE-11086 presume che tu non abbia fatto.
René Schep,

0

Può confermare l'esistenza di un problema quando si tenta di applicare SUPEE-11086una versione appena scaricata e completamente patchata di 1.9.1.1, incluso tutto fino alla patch dei grafici del dashboard di amministrazione inclusa -MPERF-10509-CE-2019-03-13-06-31-24.diff

La patch ha esito negativo nei seguenti file.

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

Questi file non hanno modifiche rispetto al commit iniziale del download v1.9.1.1. La copia dei file dall'installazione 1.9.2.4, l'applicazione di SUPEE-11086 e il confronto con l'origine v1.9.4.1 confermano che ora corrispondono.

Magento v1.9.1.1 sembra essere un po 'un problema bambino ...


Ho appena confrontato la patch 1.9.2.4 con la patch 1.9.1.0. E sembra che la differenza tra queste patch sia i 3 file che menzioni. Quindi sembra che la patch 1.9.1.0 dovrebbe essere usata su 1.9.1.1.
René Schep,

0

Può confermare l'esistenza di un problema quando si tenta di applicare SUPEE-11086una versione appena scaricata e completamente patchata di 1.9.3.0, incluso tutto fino alla patch dei grafici del dashboard di amministrazione inclusa -MPERF-10509-CE-2019-03-13-06-31-24.diff

La patch ha esito negativo in app / config.xml poiché manca il nodo seguente. Aggiungi nodo prima di eseguire SUPEE-11086, nessun problema.

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

0

Ho scoperto un nuovo problema con il modello Mage_Eav_Model_Attribute_Data_File

Nell'entità clienti, ho aggiunto gli attributi di caricamento dei file. Questi attributi non sono richiesti e quando desidero eliminare un file senza caricarne uno nuovo, l'eliminazione non funziona, poiché il valore dell'attributo non viene convalidato tramite il nuovo metodosetAttributeValidationAsPassed()

La soluzione rapida che ho fatto è nel metodo validateValue($value)

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

Da allora questo problema sembra essere presente in tutte le versioni di Magento 1.x. SUPEE-11086


0

Magento 1.9.3.1

Si è verificato un problema durante il tentativo di patch CE 1.9.3.1 utilizzando la 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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.