{"id":2321,"date":"2015-03-17T16:35:49","date_gmt":"2015-03-17T15:35:49","guid":{"rendered":"http:\/\/www.commercers.com\/blog\/?p=2321"},"modified":"2015-09-04T17:26:00","modified_gmt":"2015-09-04T15:26:00","slug":"alle-magento-versionen-von-1-4-bis-1-9-haben-eine-kritische-sicherheitsluecke","status":"publish","type":"post","link":"https:\/\/www.commercers.com\/blog\/alle-magento-versionen-von-1-4-bis-1-9-haben-eine-kritische-sicherheitsluecke\/","title":{"rendered":"Magento Versionen (von 1.4 bis 1.9) haben kritische Sicherheitsl\u00fccken – Magento Patches einspielen"},"content":{"rendered":"

Update vom 04.09.2015<\/strong><\/p>\n

F\u00fcr alle, die bei der Installation von Patches das Problem haben, dass der Server beim Aufruf der u.g. patch.php oder direkt \u00fcber SSH die Fehlermeldung Array ( [0] => ERROR: “\/app\/etc\/” must exist for proper tool work. ) <\/strong>auswirft, diese kleine Hilfestellung: In diesem Fall gibt es ein Problem mit der Variablen, die den aktuellen Installationspfad angibt. Hier muss dann die Variable durch den exakten Pfad der Magento Installation ersetzt werden.<\/p>\n

Um den exakten Pfad herauszufinden, gibt es mehrere M\u00f6glichkeiten. Hier die zwei einfachsten:<\/p>\n

    \n
  1. Per SSH \/ Shell Befehl: Einfach PWD in die Konsole eingeben. Anschlie\u00dfend spuckt das Fenster den genauen Pfad aus.<\/li>\n
  2. Wer \u00fcber unten stehende Anleitung mit der patch.php arbeitet, ersetzt die Zeile\n
    $shellBefehl = \"sh patch.sh\";<\/pre>\n
    vor\u00fcbergehend mit der Zeile<\/p>\n
    $shellBefehl = \"pwd\";<\/pre>\n
    Dann f\u00fchrt man die patch.php aus und erh\u00e4lt im Browserfenster den exakten Pfad zur Installation.<\/li>\n<\/ol>\n
    Dieser Pfad k\u00f6nnte z.B. so aussehen \/www\/htdocs\/w23drdc\/mein-shop\/magento\/ . Nun wird der Pfad kopiert und in der patch Datei (z.B. patch.sh wie unten beschrieben) ca. in Zeile bei<\/p>\n
    CURRENT_DIR=`$PWD_BIN`\/<\/pre>\n
    verwendet. Und zwar wird die Variable entfernt und durch den Pfad ersetzt. Wichtig ist jedoch, dass erstens die Anf\u00fchrungszeichen erhalten bleiben und zweitens ein abschlie\u00dfender \/ bestehen bleibt. Es k\u00f6nnte dann also so aussehen:<\/p>\n
    CURRENT_DIR=`\/www\/htdocs\/w23drdc\/mein-shop\/magento\/`<\/pre>\n
    Anschlie\u00dfend abspeichern und \u00fcber SSH oder die patch.php (s.u.) ausf\u00fchren. Nun sollte es klappen.<\/p>\n
    Welche Patches man \u00fcbrigens bereits installiert hat<\/strong>, kann man im Ordner app\/etc\/ in der Datei applied.patches.list<\/strong> sehen.<\/p>\n
    \n
    Update vom 04.08.2015<\/strong><\/p>\n
    Erneut gibt es einen Patch f\u00fcr Magento. Diesmal h\u00f6rt er auf den sch\u00f6nen Namen SUPEE-6482<\/strong>. Gleichzeitig kommt auch die neue Magento CE Version 1.9.2.1<\/strong> zum Download auf den Markt. Diese enth\u00e4lt dann bereits alle Patches. Beim neuen Patch werden sicherheitshalber verschiedene Schnittstellen Schwachpunkte gefixt, die angeblich aber noch nicht angegriffen w\u00fcrden. Alle Informationen gibt es nat\u00fcrlich auf der wieder Magento Seite.<\/a> Betroffen sind alle Magento Versionen von 1.4 bis 1.9.2.0. M\u00f6chten Sie, dass wir den Patch f\u00fcr Sie installieren? Oder mehrere, dann buchen Sie gerne unseren Installationsservice<\/a>. Mehr Informationen gibt es z.B. auch HIER<\/a>.<\/p>\n
    Zwischenzeitlich ist bekannt geworden, dass der Patch SUPEE-6285 \u00c4nderungen an der Benutzerrechte-Struktur<\/strong> im Backend vorgenommen hat (“ACL<\/strong>“). Dies \u00e4u\u00dfert sich darin, dass bei Backend-Nutzern, die KEINEN VOLLEN Backendzugriff -also eingeschr\u00e4nkte Rechte- haben, bestimmte Bereiche nicht mehr zur Verf\u00fcgung stehen und ihnen ein “404 Seite nicht gefunden” oder “404 Access denied” angezeigt wird. Das geht so weit, dass selbst die Anzeige von Gutschriften \/ Rechnungskorrekturen nicht mehr funktioniert. Dies tritt aber vor allem bei Extensions auf und nicht bei Magento-Standard-Funktionen.<\/p>\n
    \n
    Update vom 08.07.2015<\/strong><\/p>\n
    Und schon wieder gibt es einen neuen Patch f\u00fcr Sicherheitsl\u00fccken bei Magento. Dieser nennt sich SUPEE-6285<\/strong> und ist direkt auf der Magento Seite<\/a> erh\u00e4ltlich. Erh\u00e4ltlich sind Patches f\u00fcr die Magento CE Version 1.4.0.0 bis 1.9.1.1. In der gerade erschienenen Version 1.9.2.0 ist dieser Patch bereits enthalten. Da f\u00fcr \u00e4ltere Versionen bis 1.6 kein Patch vorhanden ist, muss davon ausgegangen sein, dass die Sicherheitsl\u00fccken hier wohl nicht bestehen.<\/del> Update:<\/strong> Mittlerweile stehen f\u00fcr alle Magento Versionen ab 1.4 Patches zur Verf\u00fcgung. Der Patch ist ziemlich umfangreich, daher ist eine Anwendung \u00fcber SSH oder \u00fcber die unten stehende Anleitung sehr zu empfehlen.<\/p>\n
    \n
    Urspr\u00fcnglicher Artikel:<\/strong><\/p>\n
    In allen Magento Versionen -CE und EE- besteht in allen relevanten Versionen eine Sicherheitsl\u00fccke, die es erm\u00f6glicht in die Shopinstallation zu gelangen, um dann Zugriff auf Daten und den Server zu haben. Diese L\u00fccke l\u00e4sst sich wohl auch nutzen, um Angriffe auf externe Ziele zu starten. Eine genauere Beschreibung und weitere Details gibt es im Rackspeed<\/a>Blog. Es handelt sich um den Patch SUPEE-5344<\/strong>.<\/p>\n
    Ein kleiner Hinweis (\u00fcber den von Rackspeed hinaus) f\u00fcr Personen, die keinen Shellzugriff haben und die Daten per manueller Datei\u00e4nderung anpassen wollen:<\/p>\n
    In der .sh Patch Datei den Teil mit Informationen und Hinweisen ignorieren. Nach “#9. Track patch applying result”geht es dann erst los. Immer die Datei, die hinter dem “diff” steht muss ver\u00e4ndert werden. Bei der Patch Version f\u00fcr Magento CE 1.8-1.9 sind das z.B. die Dateien<\/p>\n
    app\/code\/core\/Mage\/Admin\/Model\/Observer.php<\/p>\n
    app\/code\/core\/Mage\/Core\/Controller\/Request\/Http.php<\/p>\n
    app\/code\/core\/Mage\/Oauth\/controllers\/Adminhtml\/Oauth\/AuthorizeController.php<\/p>\n
    app\/code\/core\/Mage\/XmlConnect\/Model\/Observer.php<\/p>\n
    lib\/Varien\/Db\/Adapter\/Pdo\/Mysql.php<\/p>\n
    In diesen Dateien m\u00fcssen dann -etwas lapidar ausgedr\u00fcckt- die Zeilen, die mit einem Minus versehen sind entfernt werden und die Zeilen, die mit einem Plus versehen sind, hinzugef\u00fcgt werden.<\/p>\n
    Am einfachsten ist es jedoch die ganze Sache mit SSH zu erledigen.<\/p>\n
    Ein Tipp vor allem f\u00fcr Administratoren vieler Shops: Der ein und andere Server l\u00e4sst auch SSH Befehle per PHP zu. So kann man es sich sehr einfach machen.<\/p>\n
    Es wird z.B. eine patch.php Datei zusammen mit der patch.sh Datei in das Root Verzeichnis des Shops kopiert. Die PHP Datei enth\u00e4lt dann folgenden Code:<\/p>\n
    <?PHP\r\n\r\n$shellBefehl = \"sh patch.sh\";\r\n\r\n$shellBefehl = escapeshellcmd($shellBefehl);\r\n\r\nexec($shellBefehl,$nu);\r\n\r\nprint_r($nu);\r\n\r\n?><\/pre>\n
    Nun braucht man nur noch \u00fcber den Browser den Shop aufzurufen und ein \/patch.php an die URL zu h\u00e4ngen. Man erh\u00e4lt dann eine Success oder Error Meldung. Anschlie\u00dfend sollte man die beiden Dateien aber sicherheitshalber l\u00f6schen.<\/p>\n
    Die Verwendung der PHP Datei funktioniert selbstverst\u00e4ndlich auch bei anderen Sicherheitspatches oder Shell Befehlen, die man ohne SSH Zugriff in seinen Shop einspielen m\u00f6chte. So zum Beispiel auch bei SUPEE-1533<\/strong> und anderen.<\/p>\n
    Genutzt in Magento Versionen 1.4.0.1 bis 1.9.1.0.. Fragen, Kommentare, Anregungen? Gerne!<\/p>\n","protected":false},"excerpt":{"rendered":"
    Update vom 04.09.2015 F\u00fcr alle, die bei der Installation von Patches das Problem haben, dass der Server beim Aufruf der u.g. patch.php oder direkt \u00fcber SSH die Fehlermeldung Array ( [0] => ERROR: “\/app\/etc\/” must exist for proper tool work. ) auswirft, diese kleine Hilfestellung: In diesem Fall gibt es ein Problem mit der Variablen,…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[1247,1253,1252,1246],"class_list":["post-2321","post","type-post","status-publish","format-standard","hentry","category-allgemein","tag-sicherheitsluecke","tag-ssh-ohne-shell-zugriff","tag-supee-1533","tag-supee-5344"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/posts\/2321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/comments?post=2321"}],"version-history":[{"count":0,"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/posts\/2321\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/media?parent=2321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/categories?post=2321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.commercers.com\/blog\/wp-json\/wp\/v2\/tags?post=2321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}