WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    [UPDATE 20.08.2019]
    Mit LiveConfig v2.8.0 haben wir eine andere Lösung zur Vermeidung der zugrundeliegenden Sicherheitsprobleme implementiert.
    SetHandler und "AllowOverride FileInfo" sind mit LiveConfig v2.8 also wieder problemlos (und risikolos) möglich.
    [ENDE]


    Hallo,


    kürzlich hat uns ein Kunde auf ein mögliches Sicherheitsrisiko in der Apache-Konfiguration aufmerksam gemacht. Nach kurzer Prüfung konnten wir das Problem bestätigen und haben seitdem einen entsprechenden Patch erarbeitet.
    Das Problem ist, dass es sich hier um keinen klassischen "Bug" handelt, sondern Apache in einem bestimmten Zusammenhang schlicht keine Sicherheitsprüfung vornimmt. Bevor wir die Details näher beschreiben möchten wir aber allen Kunden noch genügend Zeit geben, um das Update zu installieren.


    Besonders auf Servern, auf denen PHP-FPM läuft, sollte dieses Update möglichst zeitnah eingespielt werden.
    Es besteht kein Risiko "von außen". Ein möglicher Angriff müsste lokal erfolgen und setzt einige Kenntnisse über die jeweilige Serverkonfiguration voraus - wir schätzen die Sache also nicht als hochkritisch, aber dennoch ernst ein.
    Weniger kritisch ist das Thema bei Servern, bei denen PHP-FPM nicht aktiviert ist oder nicht genutzt wird - aber auch hier empfehlen wir das Update bei Gelegenheit durchzuführen. Reine NGINX-Webserver sind nicht betroffen.


    Das Update (v2.7.4) aktualisiert automatisch alle Apache-vHost-Konfigurationen wie folgt:

    • die AllowOverride-Option "FileInfo" wird entfernt
    • statt dessen werden die erlaubten Anweisungen in AllowOverrideList aufgeführt


    Die Anweisung "SetHandler" ist damit ab sofort nicht mehr in .htaccess-Dateien erlaubt!


    Jede "normale" Web-Anwendung benötigt keine SetHandler-Anweisung in .htaccess. Traurige Ausnahme ist Drupal: dort enthält u.a. /sites/default/.htaccess entsprechende SetHandler-Anweisungen, um die Ausführung von hochgeladenen Dateien zu verhindern (was ohnehin ein merkwürdiges Sicherheitskonzept ist, aber da hat Drupal noch ganz andere Probleme...).
    Informationen zur .htaccess-Thematik bei Drupal haben wir (white-labeled) vorab hier bereitgestellt: https://hostinghandbuch.de/apps.drupal.htaccess
    Am Ende dieser Seite ist auch ein Aufruf aus find und sed angegeben, mit dem man alle Drupal-.htaccess-Dateien auf einem Server rekursiv patchen kann (Ausführung auf eigene Gefahr!).


    Bei Multi-Server-Umgebungen ist es egal, ob das Update zuerst auf dem Server oder auf den Clients installiert wird.


    Wir empfehlen Ihnen folgendes Vorgehen:

    • Installation des Updates auf allen Servern mit Apache
    • Identifikation aller Kunden, die .htaccess-Dateien mit SetHandler-Anweisungen verwenden:

      Code
      find /var/www -type f -name .htaccess -exec grep -Hi "^\s*sethandler" {} \;


    • Information der betroffenen Kunden, dass SetHandler nicht mehr genutzt werden darf
    • ggf. automatisches Patchen der betroffenen .htaccess-Dateien

      • zuerst speziell für Drupal:

        Apache Configuration
        find /var/www -type f -name .htaccess -exec \
sed -e 's/^\(\s*Options\s\+\)+FollowSymLinks/\1+SymLinksIfOwnerMatch/i' \
    -e 's/^\(\s*\)\(SetHandler Drupal_Security_Do_Not_Remove.*\)/\1# \!\!\! SetHandler disabled - see https:\/\/hostinghandbuch.de\/apps.drupal.htaccess\n\1#\2\n\1RewriteEngine On\n\1RewriteRule .+\\.(php[3457]?|pht|phtml|phps|pl|py|pyc|pyo|sh)$ - [F,L]/i' \
    -i {} \;





    [LIST=|INDENT=2]
    [*]dann für alle restlichen .htaccess-Dateien:

    Code
    find /var/www -type f -name .htaccess -exec \
 sed -e 's/^\(\s*SetHandler\)/# \!\!\! SetHandler disabled - see https:\/\/hostinghandbuch.de\/apps.drupal.htaccess\n#\1/i' -i {} \;


    [/LIST]

    Bei Fragen stehen wir gerne zur Verfügung.


    Viele Grüße


    -Klaus Keppler

    Zitat von RB-Media-Group

    Es werden nun nicht nur SET HANDLER bemängelt, sondern auch:


    AddDefaultCharSet
    FileETag


    Dann haben Sie eine frühere LiveConfig-Version aus dem Test-Repo installiert (vermutlich v2.7.4 <r5214).


    Das Test-Repository kann immer wieder mal instabile Versionen enthalten, wir raten daher DRINGEND davon ab, dieses Repository für die "regulären" Server zu nutzen.


    In diesem Fall müssen Sie folgenden SQL-Befehl in der LiveConfig-Datenbank ausführen:

    SQL
    UPDATE LIVECONFIG SET LC_VALUE='0005102' WHERE LC_KEY='dbschema' AND LC_VALUE = '0005103';


    Installieren Sie anschließend die aktuelle Version (2.7.4-r5214).


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ich habe einige Kunden die bislang mittels htaccess-Datei die PHP-Version gesetzt haben


    Zitat

    FcgidWrapper /var/www/XXX/conf/php71/php-fcgi-starter .php


    Nach dem Update scheint dies ebenfalls nicht mehr möglich.
    Gibt es hier eine alternative wenn es nicht über die Domain/Subdomain in LiveConfig eingestellt werden soll?

    Hmm, der Befehl FcgidWrapper ist ärgerlicherweise bei Apache nicht in den FileInfo-Overrides dokumentiert, sonst hätten wir den mit aufgenommen.


    Am einfachsten dürfte es sein, wenn Sie die Datei /usr/lib/liveconfig/lua/apache.lua bearbeiten und in Zeile 135 den Befehl "SubstituteMaxLineLength" durch "FcgidWrapper" ersetzen (*). Danach müssten Sie LiveConfig neu starten und den betroffenen Vertrag neu speichern (damit die vHost-Konfiguration aktualisiert wird).
    Wir werden FcgidWrapper beim nächsten Update auch mit in diese Liste aufnehmen (die Änderung ist daher quasi "updatesicher").
    Sicherheitstechnisch spricht aktuell nichts gegen FcgidWrapper, da hier die "normalen" suexec-Schutzmechanismen greifen.


    Viele Grüße


    -Klaus Keppler


    *) es hilft NICHT, die Anweisung "FcgidWrapper" einfach an die Liste anzufügen - nein, dafür muss leider ein anderer Eintrag dran glauben. Es gibt vermutlich einen Bug in Apache, welcher die maximale Länge der Zeile "AllowOverrideList" implizit begrenzt (laut Doku kann eine einzelne Config-Zeile max. 16MB groß sein, in der Praxis wird sie aber irgendwo klammheimlich (ohne Log-Meldung) abgeschnitten. Mehr als das, was LiveConfig aktuell rausschreibt, ist offenbar nicht drin.

    Für alle CMS-Entwickler die hier eines Tages mal mitlesen: es ist BAD PRACTICE, mittels .htaccess in die Serverkonfiguration einzugreifen. Der Schutz via SetHandler ist nett gemeint, verpufft aber sobald man z.B. NGINX einsetzt. Letztendlich wird zudem nur am Symptom herumgepfuscht (Ausführung von Dateien, die irgendwie im Webspace gelandet sind) als die eigentliche Ursache zu vermeiden (durch eine anständige Architektur, z.B. Speicherung reiner Nutzdaten außerhalb des Webspace-Roots).

    Danke für die rasche Hilfe. Die apache.lua bearbeiten hat für Abhilfe gesorgt und die Kunden können nun auch wieder den FcgidWrapper in der htaccess nutzen


    Wäre wirklich super wenn dass dann beim nächsten LiveConfig Update gleich in der Liste Berücksichtigung findet

    kk wäre es möglich dass die folgenden nginx.lua Änderungen mit in die nächste Version aufgenommen werden?


    Hallo Liveconfig,
    ich habe nun auf meinen Drupal-Webseite die htaccess-Einträge im sites/default/files Ordner angepasst, und die Rule eingebaut, die Ihr als Ersatz für den SetHandler-Befehl vorgeschlagen habt.


    RewriteEngine On
    RewriteRule .+\.(php[3457]?|pht|phtml|phps|pl|py|pyc|pyo|sh)$ - [F,L]


    Leider hat der eine sehr negative Auswirkung:
    Durch den Flag [F] werden alle Scripten abgebrochen, die auf den Files-Folder zugreifen. Viele Bild-Uploads, die in Drupal durchgeführt werden, legen automatisch von den hochgeladenen Bildern Styles an:
    So werden z.B. automatisch Bilder als Thumbnails in 150 x 150 Pixel erstellt, andere Versionen in 250 x 250 Pixel, je nach Definition durch den Programmierer, der die Webseite angelegt hat. Die Rule verhindert das Anlegen dieser Styles, die redaktionelle Tätigkeit auf den Webseiten wird komplett lahmgelegt. Meine Frage: gibt es eine alternative Rule, die zwar Scripten stoppt, die im Files-Folder liegen, aber andere Scripten zulässt? Habt Ihr andere Vorschläge, wie man die Sicherheitslücke stopfen kann?
    Danke und Viele Grüße :)
    Wolfgang

    Zitat von WolfgangS

    Leider hat der eine sehr negative Auswirkung:
    Durch den Flag [F] werden alle Scripten abgebrochen, die auf den Files-Folder zugreifen. Viele Bild-Uploads, die in Drupal durchgeführt werden, legen automatisch von den hochgeladenen Bildern Styles an:
    So werden z.B. automatisch Bilder als Thumbnails in 150 x 150 Pixel erstellt [...]


    Die o.g. RewriteRule sollte nur dann Zugriffe verbieten, wenn die abzurufende Datei direkt eine der aufgeführten Endungen (.php/.pl/.sh/usw) hat.
    Eine .jpg-Datei, die sich in dem Verzeichnis befindet, müsste problemlos abrufbar sein.


    Legen Sie testweise mal in sites/default/files/ eine Datei namens "test.txt" mit irgendeinem Inhalt an, und versuchen Sie anschließend, diese über den Browser aufzurufen.
    Welche Fehlermeldung exakt bekommen Sie? (403 forbidden oder 500 internal server error?)


    Zitat

    Habt Ihr andere Vorschläge, wie man die Sicherheitslücke stopfen kann?
    Danke und Viele Grüße :)
    Wolfgang


    Das Hauptproblem ist Drupal selbst, da es aktiv in die Serverkonfiguration eingreifen möchte. Dieser Ansatz ist gut gemeint, aber leider nicht zu Ende gedacht (z.B. sind NGINX .htaccess-Dateien völlig schnuppe).
    Wenn Sie einen komplett eigenen Server betreiben (also quasi nur einen einzigen Webspace-Vertrag auf dem Server angelegt haben), dann könnte man SetHandler dort erlauben (die Lücke wäre dann quasi wieder offen, könnte aber nicht aktiv durch "fremde" Kunden ausgenutzt werden).


    Ich vermute auf den ersten Blick, das irgendwas mit der RewriteRule oder der restlichen .htaccess-Datei nicht stimmt und deshalb der Zugriff auf die temporären Dateien nicht funktioniert - da gibt es also wahrscheinlich eine recht einfache Lösung.


    Viele Grüße


    -Klaus Keppler

    Vielen Dank für Ihre Antwort. Ich habe jetzt ausgiebig mit verschiedenen Einstellungen getestet. Eine test.txt unter "sites/default/files" konnte ich über den Browser lesen, ohne Fehlermeldung. Eine test.php wurde mit einem Fehler 403 abgewiesen. Ein selbst geschriebenes php-Script konnte aus dem Webroot heraus problemlos eine Kopie einer Jpeg-Datei, die im files-Verzeichnis liegt, anlegen.
    Auf den ersten Blick sollte alles richtig sein, trotzdem geht der upload nicht korrekt.
    Ich habe jetzt gesehen, dass das Bild in einer Variante tatsächlich hochgeladen wird, aber alle anderen Varianten wie Thumbnails etc. eben nicht angelegt werden.
    In der access-log steht lediglich, dass auf die Thumbnail-Datei nicht zugegriffen werden kann. Das ist klar, sie ist ja auch nicht angelegt.
    In der Error Log konnte ich einen Fehler produzieren: pipe broken.
    mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
    Allerdings scheint das lediglich ein Hinweis darauf zu sein, dass der Server und der Client nicht mehr miteinander kommuniziert haben.



    Ich habe jetzt eine meiner Webseiten local in einer Virtualbox-Ubuntu 18.04 Installation angelegt. Sie läuft unter php 7.2, mit Drupal 7.61
    Ich habe allen Ordnern und Dateien als owner und group "www-data" zugeordnet, und dazu für alle Ordern und Dateien 777 angelegt. Trotzdem kommt immer noch der Fehler.
    Ich habe noch die htaccess im Webroot durch die Standard-htaccess ersetzt, auch das ändert nichts an dem Fehler.
    Sobald ich aber die Rewrite-Rule auskommentiere, und den alten SetHandler Befehl wieder aktiviere, geht wieder alles so wie es soll.
    Bin für jeden Tip dankbar :)


    Wolfgang

    Hallo,


    anhand einer NGINX-Konfiguration für Drupal vermute ich, dass das am URL-Rewriting liegt: gedacht ist das so, dass wenn ein Zugriff auf den Image-Cache erfolgt und die Zieldatei aber (noch) nicht existiert, dass der Aufruf dann über die index.php geroutet werden soll (damit Drupal das gewünschte Bild dynamisch erzeugt).
    Die aktuelle RewriteRule sollte das aber eigentlich auch gar nicht verbieten...
    Wir werden mal versuchen, das mit einer Drupal-Testinstallation zu reproduzieren. Details folgen dann in Kürze...


    Viele Grüße


    -Klaus Keppler

    Also, Drupal trickst da ganz schön mittels .htaccess herum.
    Vereinfacht gesagt: in der .htaccess-Datei im Hauptverzeichnis wird eine RewriteRule gesetzt, welche Zugriffe auf nicht vorhandene Dateien pauschal durch index.php routet. Die Rewrite-Anweisungen in sites/default/files/.htaccess setzen alle anderen RewriteRules zurück - daher kommt es zu einem "403".


    Die Lösung ist also, das Routing nicht vorhandener Dateien auf die /index.php auch in die untergeordnete .htaccess aufzunehmen:

    Apache Configuration
    RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ /index.php [L]


    Damit werden die Thumbnails wieder korrekt beim ersten Aufruf erzeugt. Wir werden das in unsere Doku mit aufnehmen.
    Bei CloudFest werden wir uns zudem mal direkt mit den Drupal-Leuten über die Problematik unterhalten. ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden