Patch für "No thumb generated" unter TYPO3 4.2.10

Veröffentlicht am

Nach dem Sicherheitsupdate auf TYPO3 4.2.10 funktioniert auf Servern, auf denen PHP im SafeMode läuft, die Thumbnail-Erstellung nicht mehr (statt dem verkleinerten Bild erscheint nur "no thum generated"). Im Install-Tool sind alle Tests zu ImageMagick aber erfolgreich.

Hintergrund

ImageMagick ist keine PHP-Funktion, sondern ein externes Kommandozeilen-Programm, das von TYPO3 über den PHP-Befehl exec() aufgerufen wird. Exec-Aufrufe werden an das Betriebssystem übergeben und dort ausgeführt, und jedes Betriebssystem hat gewisse Sonderzeichen, die bei der Ausführung ein bestimmtes Verhalten hervorrufen - beispielsweise kann man mit dem Zeichen & unter Linux zwei verschiedene Befehle gleichzeitig ausführen. Ein Aufruf von "convert d&t-logo.jpg ...." würde nicht etwa das ImageMagick-Programm convert auf eine Datei "d&t-logo.jpg" ansetzen, sondern statt dessen einen Aufruf "convert d" und einen zweiten Aufruf "t-logo.jpg" starten (die in diesem Fall natürlich beide nicht funktionieren).

Dieses Verhalten kann genauso zu Fehlern führen (Bilder, die ein & im Namen haben, können nicht verwendet werden) wie zu Sicherheitslücken: Ein Benutzer in böser Absicht kann z.B. ein Bild "egal&boeses_kommando" nennen, und Linux würde dann neben einem "convert egal" auch noch ein "boeses_kommando" ausführen. Um das zu verhindern (und Linux anzuweisen, das & als ganz normalen Text zu verstehen), kann man die entsprechenden Zeichen maskieren (in der Regel durch einen vorangestellten Backslash) - Linux würde einerseits ein "convert d\&t-logo.jpg" also als einen einzelnen Befehl verstehen, andererseits würde damit auch der vollständige Dateiname an das Programm convert übergeben.

Mit dem Update auf TYPO3 v4.1.10 wurde an einigen Stellen diese Maskierung nachgebessert, um eben solche beschriebenen Sicherheitslücken zu schließen. Dabei hat man es wohl etwas zu gut gemeint und nicht bedacht, dass ein im SafeMode laufendes PHP seinerseits ebenfalls exec()-Aufrufe maskiert.

Wird jetzt bei einer betroffenen Installation ein Thumbnail benötigt, wird der convert-Befehl einmal zu oft maskiert und aus z.B. [1] wird \[1\], womit convert nichts mehr anfangen kann.

Abhilfe

Unter der Bug-ID 12431 wurde das Problem im TYPO3-Bugtracker bereits besprochen und auch ein Patch bereitgestellt. Dieser sorgt dafür, dass die in eckigen Klammern gesetzte Angabe der Ebene nicht (unnötig) maskiert wird.

Allerdings löst dieser Patch das Problem nicht in allen Fällen. Wir haben daher für die besonders hartnäckigen Fälle einen serverseitigen Patch entwickelt, bei dem das ursprüngliche combine umbenannt und gegen ein kleines Script ausgetauscht wird. Das Script wiederum ruft lediglich das ursprüngliche combine auf. Durch den zwischengeschalteten Aufruf des Scriptes werden die zuviel maskierten Parameter automatisch aufgelöst und das Problem beseitigt.

Anleitung

  1. Wechseln Sie in das Verzeichnis, in dem die im SafeMode erlaubten Programme liegen (in der Regel /usr/local/php/bin)
  2. Benennen Sie das ursprüngliche "convert" in "convert_binary" um
  3. Speichern Sie unter dem Namen "convert" folgendes Script ab:
    #!/usr/bin/php5
    <?
    /*
    Patch for bugs.typo3.org/view.php
    "Unmasks" the parameters before sending it to the convert/combine-binary
    (c) 2009 Joern Dost, D&T Internet GmbH
    */
    // $sCommand will contain the command we have to execute
    $sCommand = '';
    // Use every parameter and...
    foreach ($argv as $iCounter => $sArgument) {
    // filter out the valid chars:
    preg_match('/[-.A-Za-z0-9_\[\]\/!+]*/', $sArgument, $aParameter);
    if ($iCounter==0) {
    // Parameter 0 contains the call of this script. We change the
    // filename e.g. from /path/to/combine to /path/to/combine_binary
    $sCommand = $aParameter[0].'_binary';
    } else {
    $sCommand.=' '.$aParameter[0];
    }
    }
    // That's all. Now execute it:
    echo shell_exec($sCommand);
    ?>
  4. Machen Sie die neue Datei convert ausführbar (chmod ugo+x convert)

Anmerkungen

Dieser Patch kann nur vom Administrator des Servers, bei SharedWebspace aber nicht vom Endkunden eingespielt werden. Er ist ein "very hot fix", bei dem der jeweilige Administrator im eigenen Ermessen ggf. Erweiterungen zur Sicherheit einbauen sollte (denn letztlich "umgeht" dieses Script eine Maskierungs-Runde, dieses Verhalten kann daher wieder ausgenutzt werden, um Schadcode einzuschleusen). Und - um auf Nummer sicher zu gehen, dass kein Schadcode eingeschleust werden kann - Sonderzeichen wie & in Dateinamen werden gar nicht erst erlaubt (selbst wenn TYPO3 ansonsten mit solchen Dateinamen klar käme).

Weitere Hinweise:

TYPO3