Magento 1.5.0.0 Sicherheitswarnung

Pünktlich zur Magento Imagine ist Magento 1.5 erschienen - da war wohl einiges an Druck hinter. So zumindest kann ich mir erklären das die Version mit einer größeren Sicherheitslücke veröffentlicht wurde. So ist es möglich, über die get.php die komplette Verzeichnisstruktur mit allen Dateien abzugrasen. Das erlaubt es z.B. die local.xml, in der alle Datenbank-Zugriffe vorhanden sind, anzusehen.

Im Blog Ajzele heißt es im Artikel Imagine this, Magento 1.5.0.0 Security Flaw Edition

Shockingly there is a file called get.php in a root of Magento. OK, that fact alone is not that shocking. Try running something like http://{{unsecure_base_url}}/get.php/app/etc/local.xml where {{unsecure_base_url}} is your test host/domain. It will nicely return entire content of the config.xml file.

Magento 1.5 sollte somit in Verbindung mit der get.php im Live-Betrieb erst einmal nicht eingesetzt werden. Zudem würde ich ohnehin allen Shop-Betreibern raten mit dem Update auf die 1.5 so lange zu warten bis die Dienstleister ein wenig mit Upgrades von Version 1.4 auf 1.5 geübt haben und Erfahrungen gesammelt sind.

Magento hat auf das Sicherheitsproblem im übrigen schon reagiert und die get.php in Version 1.5.0.1 entfernt. Ob das das Problem nun wirklich löst möchte ich bezweifeln - die Datei wird ja nicht völlig ohne Sinn in Magento vorhanden gewesen sein.

Die get.php diente, wirft man einen Blick in den Source, übrigens dem Auslesen von Daten aus einem Datenbank-Storage:

$databaseFileSotrage = Mage::getModel('core/file_storage_database');
$databaseFileSotrage->loadByFilename($filename);

if ($databaseFileSotrage->getId()) {
    $directory = dirname($filePath);
    if (!is_dir($directory)) {
        mkdir($directory, 0777, true);
    }

    $fp = fopen($filePath, 'w');
    if (flock($fp, LOCK_EX | LOCK_NB)) {
        ftruncate($fp, 0);
        fwrite($fp, $databaseFileSotrage->getContent());
    }/* else {
        while (!flock($fp, LOCK_EX | LOCK_NB)) {
            usleep(1000);
        }
    }*/
    flock($fp, LOCK_UN);
    fclose($fp);
}

if (file_exists($filePath) || is_readable($filePath)) {
    $transfer = new Varien_File_Transfer_Adapter_Http();
    $transfer->send($filePath);
    exit;
}



Ein Beitrag von Tobias Vogt
Tobias's avatar

Tobias Vogt arbeitet seit 2008 mit Magento und ist seit 2011 durch Magento zertifizierter Entwickler. Seit 2016 ist er Mitgründer und CTO bei der connect-io GmbH, einer Magento-Agentur mit Sitz im idyllischen Paderborn-Salzkotten. Er gehört zum Gründer-Team der Webguys und ist seit November 2011 Bachelor of Science (Wirtschaftsinformatik). Sie erreichen Ihn per E-Mail unter tobi@webguys.de.

Alle Beiträge von Tobias

Kommentare
Michael am

Wo kommt den eigentlich der Release-Druck her. Ebay? Auch der neue Downloader ist nicht zu gebrauchen. Ich habe mal versucht ein paar Probleme aufzuzeigen. Unter http://auit.de/news/magento-1-5-0-1-stable-downloader-was-soll-das-88-article#zusammenfassung gibt’s mehr.

Michael am

Ein kleine Frage in diesem Zusammenhang. Will jetzt nicht unbedingt auf die neueste "stable" upgraden. Das würde aber passieren bei der Verwendung des Keys: magento-core/Mage_All_Latest per Pear oder im MCM. Gibt es hier auch einen passenden Key für 1.4.2 ?

Tobias Vogt am

Aber schon Schräg. Ein Bug, was tun? Ach, Feature weg.

Damian am

Kann mich da nur Vinai anschließen. Das Feature ist erstmal wieder rausgenommen worden. Eine aktualisierte EE gibt es wohl nocht nicht. Die haben die 1.10 erstmal komplett weggenommen.

Vinai am

Mist, zu früh abgeschickt X) DIe get.php war Teil einer alternativen Image-Storage Implementierung, bei der Bilder in der DB gespeichert werden. Diese Möglichkeit hat Magento in 1.5.0.1 entfernt, damit sollte zumindest diese Lücke geschlossen sein ;)

Tobias Vogt am

Mhh.. Ja aber damit fehlt doch auch die Funktion der get.php oder ist das irgendwie anders implementiert?

Vinai am

Moin,

peinliche Sache! Aber keine 12 Stunden später ist ja 1.5.0.1 released worden in welcher die get.php nicht mehr existiert.

Dein Kommentar