Neuer Patch supee-6788 zum Anwenden von Patches


29

Nach wochenlangem Warten auf den Patch heute (27.10.2015) wurde er veröffentlicht: SUPEE-6788

Viele Dinge wurden gepatcht und es wird empfohlen, installierte Module auf mögliche Schwachstellen zu überprüfen.

Ich öffne diesen Beitrag, um einige Einblicke in die Anwendung des Patches zu erhalten. Was sind die Schritte, um den Patch anzuwenden? Nach meinem Verständnis sind dies die Schritte:

  1. Korrigieren Sie Module mit Administratorfunktionen, die sich nicht unter der Administrator-URL befinden
  2. Korrigieren Sie Module, die SQL-Anweisungen als Feldnamen oder Escape-Felder verwenden
  3. Whitelist-Blöcke oder Direktiven, die Variablen wie {{config path=”web/unsecure/base_url”}}und verwenden{{bloc type=rss/order_new}}
  4. Potenzielle Exploits mit dem Dateityp "Benutzerdefinierte Option" ansprechen (keine Ahnung, wie das geht)
  5. Wenden Sie den Patch an

Ist das die richtige Vorgehensweise?


1
Aktuelle CE-Versionen 1.7.0.0 bis 1.9.2.0
Fiasco Labs

5
Der Patch ändert sich .htaccess.sampleebenso wie .htaccess. Letzteres wird in den meisten Shops angepasst. Dadurch schlägt der Patch fehl => Sie müssen ihn vorübergehend durch die Originaldatei von Magento ersetzen, den Patch anwenden, Ihre eigene .htaccess-Datei wiederherstellen und die Änderung anwenden, die den Zugriff auf cron.phpmanuell schützt (don ' Natürlich nicht mit dem Produktionssystem!)
Fabian Schmengler

1
Was ist mit denen, die Nginx verwenden?
Lloiacono

4
Ich stimme dafür, diese Frage als "Off-Topic" zu schließen, da es keine Frage gibt. Bitte verschieben Sie die Diskussionen in den Chat
7ochem

2
Es gibt eine Frage im Titel des Beitrags, auch im letzten Absatz bin ich genauer. Ungeachtet dessen sind solche Posts meiner Meinung nach sehr nützlich, um Kommentare und Best Practices beim Anwenden eines neu veröffentlichten Patches zu zentralisieren.
Lloiacono

Antworten:


33

Im Allgemeinen können Sie den Patch wie alle vorherigen anwenden. Schauen Sie sich die offiziellen Unterlagen an und überprüfen Sie diesen SE-Beitrag . Aber ja, es gibt einige zusätzliche Punkte, die Sie überprüfen sollten, wenn Sie diesen Patch anwenden. Byte / Hypernode hat einen schönen Beitrag dazu.

  1. Überprüfen Sie, ob Ihr Thema eine benutzerdefinierte template/customer/form/register.phtmloder benutzerdefinierte hat template/persistent/customer/form/register.phtml. Wenn dies der Fall ist, stellen Sie sicher, dass a form_key.
  2. Überprüfen Sie, ob Ihr Thema eine benutzerdefinierte hat layout/customer.xml. Stellen Sie in diesem Fall sicher, dass Sie die erforderlichen Änderungen aus dem Patch ( customer_account_resetpasswordgeändert in customer_account_changeforgotten) übernehmen.
  3. Verwenden Sie nicht standardmäßige Variablen in CMS-Seiten, statischen Blöcken oder E-Mail-Vorlagen? Stellen Sie dann sicher, dass Sie sie auf die Whitelist setzen. In dieser SE-Frage erfahren Sie, wie Sie Variablen / Blöcke auf die Positivliste setzen.
  4. Führen Sie die cron.phpüber HTTP? Stellen Sie sicher, dass Sie besser verwenden cron.sh. Wenn dies nicht möglich ist, stellen Sie sicher, dass Sie cron.php über CLI PHP aufrufen. Wenn Sie aus irgendeinem Grund keinen richtigen Cronjob konfigurieren können und ihn über HTTP ausführen müssen, lesen Sie diese SE-Frage
  5. Stellen Sie sicher, dass alle Ihre Erweiterungen das "neue" Admin-Routing verwenden. Sie können dieses n98-magerun- Plugin verwenden, um dies zu überprüfen. Sie können dieses CLI-Skript auch verwenden . Sie können sich auch diese verwandte SE-Frage ansehen .
    1. Wenn alle Ihre Erweiterungen das richtige Admin-Routing verwenden, müssen Sie unter System - Konfiguration - Admin - Sicherheit die Option "Kompatibilitätsmodus für Admin-Routing aktivieren" deaktivieren.
  6. Wenn Sie M2ePro verwenden, aktualisieren Sie es auf die neueste Version, da alte Versionen mit dem neuen Patch nicht funktionieren.

Stellen Sie beim Aktualisieren sicher, dass Sie die Datei löschen dev/tests/functional/.htaccess. Es ist in Magento 1.9.2.2 nicht mehr vorhanden. Wenn Sie es behalten, sind Sie immer noch verwundbar.

Überprüfen Sie in jedem Fall Ihre Seite nach dem Update mit MageReport , um festzustellen , ob alles gut gelaufen ist .

Es gibt auch einen technischen Blogbeitrag von Piotr , der die kritischen Änderungen beschreibt.


Nur eine kleine Anmerkung, das CLI-Skript erwähnt "Überprüfen Sie, ob alles in Ordnung ist, und deaktivieren Sie dann den Administrator-Controller-Kompatibilitätsmodus". Ich denke, sie meinen das Gegenteil, um es zu ermöglichen. Ist das richtig?
Michael

1
@kaska Wenn alle Ihre Erweiterungen in Ordnung sind, müssen Sie den Kompatibilitätsmodus deaktivieren .
Simon

Sollten Sie / dev in einer Produktionsumgebung nicht vollständig entfernen?
paj

1
@paj theoretisch ja. Aber mit Version 1.9.2.2 ist es mit einem .htaccess geschützt, daher sollte es in Ordnung sein, es beizubehalten. Befolgen Sie einfach die oben genannten .htaccess-Anweisungen.
Simon

Vielen Dank für die Vollständigkeit, sie sollten Sie das nächste Mal die komprimierten Release Notes schreiben lassen! Super hilfreich!
Asherrard


3

Stellen Sie für Nginx sicher, dass Sie den Zugriff auf cron.php und den dev-Ordner blockieren. Wir benutzen diesen Block:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }

Ihr regulärer Ausdruck funktioniert nicht, da Sie nur nach dem Verzeichnis suchen. "report / config.xml, cron.php" stimmen also nicht überein, und am Ende befindet sich ein vertikaler Strich oder ein Pipe-Symbol. Kopieren-Einfügen? Verwirren Sie Regex auch nicht mit / app /, wenn Sie etwas verlegen, wird es gehackt.
MagenX

Ungültiger Kopier- und Einfügejob, sorry. Hinzugefügt im? am Ende ist also der abschließende Schrägstrich optional. Habe es gerade getestet und es funktioniert wie es sollte.
Adam L.

Auch diese Regex ist anfällig, Sie haben ^ /, stellen Sie sicher, dass Sie Ihre Quelldateien nicht in den obersten Ordner kopieren, wie / old /, / upgrade / etc
MagenX

@MagenX Sie sagen also, dass diese Regex schuld ist, wenn Sie keine Versionskontrolle oder Standard-Systemadministrations-BCP verwenden?
Melvyn

1

Ich habe den Patch gerade auf meinen 1.10.1 EE angewendet und dies verursacht Nebenwirkungen auf nativen Bildschirmen, da der Core nicht APPSEC-1063-kompatibel ist:

Beispiel:

Im app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

Sie finden 2 addFieldToFilterAnrufe, die nicht APPSEC-1063-konform sind.

Dies ist ein Verstoß gegen die Raster "Kunde"> "Attribut". Daher müssen Sie den Patch mit dem im PDF "SUPEE-6788-Technical% 20Details% 20.pdf" im Abschnitt "APPSEC-1063" empfohlenen Trick patchen

Ändern der mehreren

    $this->addFieldToFilter($field, 0);

(wobei das $ -Feld komplexe (CASE .. WHEN THEN ...) SQL-Anweisungen enthält)

in

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

Sowohl die supee-6788-Toolbox von rhoerr als auch die gaiterjones haben diese Art von Problemen nicht erkannt. Ich habe alle anderen überprüft -> addFieldToFilter ($ und keine scheinen das Problem zu verursachen.

Andere betroffene 1.10-Kerndateien: (gefunden von Rhoerrs supee-6788-Toolbox)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php 

Es kann mehr geben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.