WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

kk · 11. Februar 2019

[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

RB-Media-Group · 12. Februar 2019

Hallo

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

AddDefaultCharSet
FileETag

Mit freundlichen Grüßen

Martin Krüger

kk · 12. Februar 2019

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

RB-Media-Group · 12. Februar 2019

Hallo

auf dem Testserver ist und war bereits 2.7.4 r5214 installiert. Wir werden es weiterhin beobachten.

Mit freundlichen Grüßen

Martin Krüger

kk · 12. Februar 2019

Zitat von RB-Media-Group

auf dem Testserver ist und war bereits 2.7.4 r5214 installiert. Wir werden es weiterhin beobachten.

Dann war aber trotzdem irgendeine frühere Testversion aus dem Repo (r5210 oder r5212) mal installiert, sonst wäre das o.g. Problem nicht aufgetreten.

bravesurfer · 12. Februar 2019

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?

antondollmaier · 12. Februar 2019

Achtung: NEOS ist auch betroffen, dort wird der SetHandler auch verwendet:

Code

# Prevent execution of script files
SetHandler default-handler
<Files *>
  # Override again if executed later in the evaluation list
  SetHandler default-handler
</Files>

kk · 12. Februar 2019

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.

kk · 12. Februar 2019

Zitat von antondollmaier

Achtung: NEOS ist auch betroffen, dort wird der SetHandler auch verwendet

Danke für den Hinweis, wir werden das mit in die Doku aufnehmen.

kk · 12. Februar 2019

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).

bravesurfer · 12. Februar 2019

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

Stricted · 17. Februar 2019

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

Diff

nginx.lua  | 12 ++++++++++++
 1 files changed, 12 insertions(+)


diff --git a/nginx.lua b/nginx.lua
index 83a1129..f4d7f93 100644
--- a/nginx.lua
+++ b/nginx.lua
@@ -1007,6 +1007,10 @@ local function writePHPconfig(fh, opts, php, phpVersionsFCGI)
     fh:write("\t\ttry_files $fastcgi_script_name =404;\n")
     fh:write("\t\tfastcgi_split_path_info ^(.+\\.php)(/.*)$;\n")
     fh:write("\t\tinclude /etc/nginx/fastcgi_params;\n")
+    if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
+      fh:write("\t\t# Include customer-specific configuration options:\n")
+      fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
+    end
     fh:write("\t\tset $path_info $fastcgi_path_info;\n")
     fh:write("\t\tfastcgi_param PATH_INFO $path_info;\n")
     fh:write("\t\tfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n")
@@ -1029,6 +1033,10 @@ local function writePHPconfig(fh, opts, php, phpVersionsFCGI)
         fh:write("\t\ttry_files $fastcgi_script_name =404;\n")
         fh:write("\t\tfastcgi_split_path_info ^(.+\\.php)(/.*)$;\n")
         fh:write("\t\tinclude /etc/nginx/fastcgi_params;\n")
+        if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
+          fh:write("\t\t# Include customer-specific configuration options:\n")
+          fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
+        end
         fh:write("\t\tset $path_info $fastcgi_path_info;\n")
         fh:write("\t\tfastcgi_param PATH_INFO $path_info;\n")
         fh:write("\t\tfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n")
@@ -1341,6 +1349,10 @@ function configureVHost(cfg, opts, cnames)
               end
               fh:write("\tlocation / {\n")
               fh:write("\t\tset $proxy_host ", host, ";\n")
+              fh:write("\t\tproxy_set_header\tHost\t$host;\n")
+              fh:write("\t\tproxy_set_header\tX-Real-IP\t$remote_addr;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-For\t$proxy_add_x_forwarded_for;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-Proto\t$scheme;\n")
               fh:write("\t\tproxy_pass\t", proto, "://$proxy_host", path, "$request_uri;\n")
               fh:write("\t}\n")
             end

Alles anzeigen

WolfgangS · 25. Februar 2019

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

kk · 25. Februar 2019

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

WolfgangS · 26. Februar 2019

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

kk · 26. Februar 2019

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

kk · 26. Februar 2019

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.

WolfgangS · 27. Februar 2019

Vielen Dank für die Hilfe. Ich wäre nicht drauf gekommen, da ich mich zu wenig mit rewrite-Rules auskenne!
Viele Grüße
Wolfgang

antondollmaier · 28. Februar 2019

kk: bitte den ersten Beitrag auf die neuen RewriteRule anpassen. Danke!

TCRserver · 3. März 2019

Hallo Herr Keppler,
seit zwei bis drei Wochen gibt es eine #5244 als Preview, aber keine Ankündigung dazu.
Was verbirgt sich denn hinter der Version?

Jetzt mitmachen!