Güvenlik Düzeltme Eki SUPEE-11086 - Muhtemel sorunlar?


24

Magento, M1 için yeni bir güvenlik düzeltme eki ve M1 ve M2 için güncellemeler yayınladı.

Bu sürümler kritik güvenlik düzeltmelerini içerir. "Tüm tüccarların mümkün olan en kısa sürede yükselmelerini şiddetle tavsiye ediyoruz."

Bu düzeltme ekini yükseltirken veya uygularken hangi sorunları dikkate almalıyım?

SUPEE-11086

SUPEE-11086, Magento Commerce 1.14.4.1 ve Açık Kaynak 1.9.4.1, uzaktan kod yürütme (RCE), siteler arası komut dosyası çalıştırma (XSS), siteler arası istek sahteciliği (CSRF) ve diğer güvenlik açıklarını kapatmaya yardımcı olan birden fazla güvenlik geliştirmesi içerir.

Magento 2.3.1, 2.2.8 ve 2.1.17 Güvenlik Güncellemesi

Bu sürümler birden çok işlevsel ve güvenlik güncellemesi içerir. Risk: 2.1.17, 2.2.8 ve 2.3.1'den önce Magento Ticareti ve Magento Açık Kaynağı için Kritik.


Ryan Hoerr, Magento 2.3.1, 2.2.8 ve 2.1.17 Güvenlik Güncellemesi için farklı bir soru oluşturmanız gerektiğini düşünüyorum
Amit Bera

2
1.8.0 / 1.8.1 sürümünün neden olmadığı hakkında fikrin var mı?
Jason,

Yanıtlar:


20

Bulunan en büyük sorun: Mage::log()yanlış çalışıyor. Bu işlevi özel günlük dosyasıyla çağırırsanız (ve henüz mevcut değilse), SUPEE-11086'ya eklenen ek doğrulama nedeniyle günlük dosyaya yazılmaz.


Bu sorun aynı zamanda Magento CE 1.9.4.1 için de geçerlidir: magento.stackexchange.com/questions/268229/…
Aad Mathijssen

5
tüm günlüklerim tamamen durdu. Hatta Sistem ve istisna günlükleri. Bunun için bir düzeltme var mı?
Kalvin Klien

Mage :: log tarafından yazılan tüm log dosyalarım da durdu. M1 EE 1.14.0.2
PromInc,

tek düzeltme kodunu geri döndürmektirMage::log()
Aswerer

3
25 Haziran itibariyle, Magento, Mage::log()yöntem için bir düzeltme içeren SUPEE-11155, Magento Commerce 1.14.4.2 ve Magento Açık Kaynak 1.9.4.2'yi yayımladı .
Aad Mathijssen

11

Önemli: yama adı, düzeltme ekinin uygulandığı en yüksek sürümü içerir. Dolayısıyla 1.9.3.10 için bir düzeltme eki 1.9.3.10, 1.9.3.9, .... için başka bir eke uygulanacaktır. Bir sonraki sürümde isimlendirmeyi geliştirmeye çalışacağız ve https://github.com/steverobbins/magedownload-cli dosyasını API üzerinden sürüm meta verilerini doğru şekilde görmesi gerektiği gibi kullanabilirsiniz .


5

Diğerleri gibi günlük dosyalarım da veri yazmayı tamamen bıraktı.

Hata kaynağı - günlük dosyaları veri yazma

İçinde app/Mage.phpbu değişikliği yaptılar:

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

hangi onaylı dosya uzantıları virgülle ayrılmış listesi için config arıyor. Ancak bu listeyi config 'e eklememişlerdi - Mage Admin' de kendi başımıza yapmamız için bir seçenek bile değil.

Hata Çözüm - Günlük Dosyaları Veri Yazmıyor

Bunu çözmek için, core_config_datatablodaki veritabanına bir giriş yapmanız yeterlidir .

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

Nesneler önbelleğini de temizlediğinizde, verileri bir kez daha günlük dosyalarına yazarken görmelisiniz.

ls -lrt var/log/ | tail


Başvuru için, bu sorun tüm güvenlik yamaları uygulandığında EE 1.14.2.0'daydı.

Bu konuda Magento Desteği ile bir bilet açtım ancak henüz bir teknisyenden bir yanıt almadım. Sıradayım.


Bu hata konusunda beni şaşırtan şey, Magento'nun 2017 sonunda SUPEE-10415 aracılığıyla ekledikleri günlük dosya uzantılarını doğrulamak için bir yönteme sahip olduğudur.

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

Eksik bir günlük iadesini yeniden icat etmek yerine neden bu mantığı tekrar kullanmadılar?


3
Bu doğru değil. App / etc / config.xml dosyasında allowFileExtensions yapılandırma olarak eklendi. Veritabanında yoksa, bu kullanılacaktır. Asıl sorun, yeni doğrulama işlevinin ilk önce dosyanın mevcut olup olmadığını görmeye çalışmasıdır, ki bu çok hoş karşılanmayabilir.
René Schep

RenéSchep @ @ işaretini eklediğiniz için teşekkür ederiz. Daha derinlemesine bakıldığında, config.xml dosyam kod tabanımızın geri kalanıyla farklı bir depoda yaşıyor. Bu nedenle, bu düzeltme ekini değiştirdiğimde, yapılandırma dosyası bu değişiklikle güncellenmedi. Var olmayan dosyalara yazı yazmamaya gelince, kişisel olarak bunu sunucularımda çalışacağını buluyorum. Bunun, dosya sisteminin kendisinde bir klasör izinleri sorunu olup olmadığını merak etmeme neden oluyor. Ancak bu koda çok fazla bakmadım.
PromInc

Test ettiğimden, eğer dosya zaten mevcutsa işe yaradığı. İlk kontrol isValid, dosyanın okunabilir olup olmadığını kontrol eder. Eğer yoksa, dosyayı oluşturma girişimi yoktur ve yanlış döndürülür.
René Schep

@ RenéSchep nasıl düzeltebiliriz? Magento desteği a ** h'de ağrıdır. Cevap vermede çok yavaşlar.
Adarsh ​​Khatri

@AdarshKhatri, Magento'nun yazabilmesi için önce dosyayı oluşturmanız gerekir. /path/to/magento/install/html/var/log/newlogfile.log
PromInc

4

Mage::log()başlangıçta yoksa, günlük dosyalarına hiçbir şey yazamaz. Bunun nedeni , arama yapılırken bulunmayan bir hatayı atma isValidişlevidir . Bunu , günlük dosyası gerçekten oluşturulduktan sonra try / catch'e taşıyarak ve doğrulama başarısız olursa dosyayı kaldırarak geçici olarak düzelttim :Zend_Validate_File_ExtensionZend_Loader::isReadable($value)isValid

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

        ...
    }
}

Daha katı bir şey elde edene kadar bu kesinlikle geçici bir çözüm.


3

1.9.3.10 yamasıyla ilgili olası sorun

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

Yamada biz varız:

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

ancak, 1.9.3.10'daki koda bakın (LTS üzerinden). Söz konusu kodu görmüyorum:

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

AMA, 1.9.4 için var

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

Muhtemel sebep, daha önce uygulanmayan eksik bir yamadır.


4
SUPEE-10975 yamasını kaçırıyorsunuz.
Richard Feraro

mmm, yama setlerime göre, bu zaten uygulandı: 2018-12-29 23:16:30 UTC | SUPEE-10975_CE_v1.9.3.10 | CE_1.9.3.10 | v1 | 91395a467666d7381ff4f9629f52a1d406eee65a | Perşembe 8 Kasım 13:45:47 2018 +0200 | ce-1.9.3.10-dev
ProxiBlue

En son yamanın dosya adı PATCH_SUPEE-10975_CE_v1.9.3.10_v1-2018-11-27-09-14-43.sh, sizinki sanırım son 8 Kasım 2018'de yayınlanmış gibi görünüyor.
Richard Feraro

1
PATCH_SUPEE-10975'i geri aldım ve yeniden uyguladım, sonra en son yeniden uygulandı, hepsi işe yaradı
ProxiBlue

Bu, SUPEE-10975’de Müşteri Gruplarını silememenize neden olan bir hataydı. Manuel olarak düzeltmiş gibisiniz, bu da yeni yamanın başarısız olmasına ve bu da onu düzeltiyor.
René Schep

3

PATCH_SUPEE-11086_CE_1.9.1.0_v1-2019-03-26-03-03-13.sh kullanarak yamayı Magento 1.9.0.1'e yüklemeye çalışıyorum

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

Aşağıdaki kodu 'app / etc / config.xml'den kaldırarak ve yamayı tekrar çalıştırarak düzelttim.

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

3

Ayrıca M1 yamaları için isim konusunda biraz kafam karıştı.

Eski yamalar için kendilerine adlandırdılar SUPEE-10975 for CE 1.9.3.4-1.9.3.10ya da SUPEE-10888 for CE 1.9.2.0-1.9.2.4 (0.07 MB)şimdi sadece bir sürüme hitap ediyor PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh.

Geçerli düzeltme eki, küçük bir sürümün tüm sürümlerine mi yoksa yalnızca sonuncusuna mı hitap ediyor?

1.9.3.1 mağazasında bir test yaptım ve her şey geçti ancak bunun diğer sürümler için doğru olup olmadığından emin değilim.


Teşekkürler Ryan! Bu, @jason sorusunun cevabını da "1.8.0 / 1.8.1 için neden sürüm olmadığı konusunda bir fikriniz var mı?" Bunun için 1.7.0.2 Yaması ile gitmeli, değil mi? Daha önce birçok küçük bültene hitap eden yamalar olduğunu bilmiyordum.
Sebastian,

2
@RyanHoerr emin misin? Magento.stackexchange.com/questions/267576/… başka bir iş parçacığında olduğu gibi, tam tersi değil mi? Eski adlandırma stilinden tahmin edersek, PATCH_SUPEE-11086_CE_1.7.0.2_v1-2019-03-26-03-02-36.sh uygulamasının 1.7.0.0 ile 1.7.0.2 arasında uygulanabileceğini ve Her yamanın sürüm numarası bu durumda son olurdu . Magento'dan birileri, lütfen bu yeni adlandırma stilinin arkasındaki mantığın ne olduğunu onaylayabilir mi? Şimdiden Thx ..
Antoine Kociuba

2
@AntoineKociuba ile gideceğim 2 farklı 1.8.1 mağazasıyla 4'e rastladım 1.7.0.2 Düzeltme Eki: - app / code / core / Mage / Usa / etc / system.xml Hunk # 4 845'te başarısız oldu - app /etc/config.xml Hunk # 1 144 - başarısız / app / locale / en_US / Mage_Widget.csv Hunk # 1 - 6 / lib / Varien / Filter / Template.php Hunk # 1 - 254'te başarısız oldu, 1.9.1.0 çalışıyor sorunsuz. 1.9.3.1 deposuyla aynı: 1.9.2.4 yaması çalışıyor, 1.9.3.10 da çalışıyor.
Sebastian,

3
@RyanHoerr bu yanlıştır. Bu ad, bir yamanın uygulandığı en son sürümü içerir. Dolayısıyla 1.9.3.10 için bir düzeltme eki 1.9.3.10, 1.9.3.9, .... için başka bir eke uygulanacaktır. Bir sonraki sürümde isimlendirmeyi geliştirmeye çalışacağız ve ayrıca sürümleri API üzerinden düzgün bir şekilde meta verileri görmesi gerektiği için github.com/steverobbins/magedownload-cli de kullanabilirsiniz .
Piotr Kaminski

Kötü bilgim kaldırıldı. Düzeltme için teşekkürler.
Ryan Hoerr,

2

Magento 1.9'da log kesilmesi. SUPEE-11086 yamasında günlük kaydını düzeltmek için:

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

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

Umarım bu yardımcı olur!


1

M1 için yamadaki tüm yeni PHP dosyalarında işlenmemiş şablon vars var

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

Sorun değil, yanlış görünüyor. SUPEE-10975’ten sonra da aynı duyguyu yaşadım.


1

Günlük dosyalarının artık oluşturulmadığını ve yalnızca günlük dosyası zaten mevcutsa yazıldığını anladım. Bu çizgiden kaynaklanıyor gibi görünüyor:

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

app / Mage.php adresinden. Bunu eski mantığı kullanarak düzelttim. Bu yüzden yukarıdaki satırı aşağıdaki ile değiştirin:

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

0

app / code / core / Mage / Adminhtml / Block / Müşteri / Grup / Edit.php Hunk # 1'i kontrol ettim. 57'de başarısız oldu. 1'in 1'i başarısız oldu

Yama 10975'te bu noktada bir hata vardı. Return ifadesi eksikti. Belki 10975 düzeltme ekini uyguladıktan sonra bu hatayı düzelttiniz ya da değişikliği yoksaydınız. Hata 11086'da giderildi. Bu kod satırı zaten sizin tarafınızdan ayarlandı / yoksayıldıysa, yeni düzeltme ekini uygularken tanımladığınız hatayla sonuçlanacaktır. Eğer hatayı kendiniz düzelttiyseniz, yama dosyasındaki bloğu kaldırın ve yamayı yeniden çalıştırın.


1
SUPEE-11086'nın çalışması için "daha az resmi" olan SUPEE-11043 yamasını geri almak zorunda kaldım
Jeroen Vermeulen - MageHost

0

SUPEE-11086'yı Kullanma | CE_1.9.1.0, yukarıda Ryan Hoerr tarafından önerildiği gibi.

SUPEE-11086 Uygulaması | CE_1.9.1.0 | v1 | 3f120e6a795eed55267bd2b9164b3984913ddfc9 | Cum 22 Mart 18:40:11 2019 +0000 | 4f3f369e723fe31212cb5be9adda113f891d7f62..HEAD

CE_1.9.2.1’e

Her dosyada bir Fail alıyorum.

Düzeltme ekini başarıyla başka depolara uyguladım.

Çekirdek koduna dokunulmamış.

Uygulanan yamalar listesi

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

Açıklama için @AntoineKociuba teşekkürler. Önceki yamaların hepsinin doğru olduğunu doğruladım, ancak 1.9.2.1 kurulumum için PATCH_SUPEE-11086_CE_1.9.2.4_v1 altında belirtilen doğru yamayı uyguladığımda, hala bir parça dışında bir hata alıyorum. Manuel bir yama önerir misiniz?
Bevan Holman

Hangi aksama gideceksin?
René Schep

Bu sorun çözüldü, yeni bir repo klonu almak zorunda kaldım. Teşekkürler René
Bevan Holman

0

M1.9.3.7 Düzeltme Eki ile İlgili Sorunlar 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

App / code / core / Mage / Adminhtml / Block / Customer / Group / Edit.php olarak görünmüyor. SUPEE-11086'nın sizin yapmadığınızı varsaydığı SUPEE-11043 yamasını uyguladınız.
René Schep

0

SUPEE-11086Admin Dashboard Charts Patch dahil olmak üzere her şey dahil olmak üzere 1.9.1.1'in yeni indirilmiş ve tamamen yamalı sürümüne başvurmaya çalışırken bir sorun olduğunu onaylayabilir -MPERF-10509-CE-2019-03-13-06-31-24.diff

Düzeltme eki aşağıdaki dosyalarda başarısız olur.

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

Bu dosyalar v1.9.1.1 indirmesinin ilk işlemesinde değişiklik yapmaz. 1.9.2.4 kurulumundan dosyaları kopyalamak, SUPEE-11086 uygulamak ve sonra v1.9.4.1 kaynağı ile karşılaştırmak, şimdi eşleşdiklerini onaylar.

Magento v1.9.1.1 biraz problemli bir çocuk gibi görünüyor ...


1.9.2.4 yamasını 1.9.1.0 yamasıyla karşılaştırdım. Ve bu yamalar arasındaki fark, bahsettiğiniz 3 dosyadır. Dolayısıyla 1.9.1.0 yamasının 1.9.1.1'de kullanılması gerektiği gibi görünüyor.
René Schep

0

SUPEE-11086Admin Dashboard Charts Patch dahil olmak üzere her şey dahil olmak üzere 1.9.3.0'ın yeni indirilmiş ve tamamen yamalı sürümüne başvurmaya çalışırken bir sorun olduğunu onaylayabilir -MPERF-10509-CE-2019-03-13-06-31-24.diff

Yama, aşağıdaki düğüm eksik olduğundan app / config.xml dosyasında başarısız oluyor. SUPEE-11086'yı çalıştırmadan önce düğüm ekleyin, sorun yok.

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

0

Modelle yeni bir sorun keşfettim Mage_Eav_Model_Attribute_Data_File

Müşteriler adına dosya yükleme özellikleri ekledim. Bu nitelikler gerekli değildir ve yeni bir dosya yüklemeden bir dosyayı silmek istediğimde silme çalışmıyor, çünkü özellik değeri yeni yöntemle doğrulanmadısetAttributeValidationAsPassed()

Yaptığım hızlı düzeltme yöntemde validateValue($value)

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

Bu sorun o zamandan beri tüm Magento 1.x sürümlerinde mevcut görünmektedir. SUPEE-11086


0

Magento 1.9.3.1

PATCH_SUPEE-11086_CE_1.9.3.10_v1.sh yamasını kullanarak CE 1.9.3.1'i yamalamaya çalışırken sorun oluştu:

checking file app/code/core/Mage/Adminhtml/Model/LayoutUpdate/Validator.php
Hunk #1 FAILED at 69.
1 out of 1 hunk FAILED
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.