Startseite » Forum » LiveConfig-Foren (deutsch) » Ankündigungen & neue Versionen » WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 24
  1. #11
    Benutzer
    Registriert seit
    11.10.2013
    Beiträge
    72
    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

  2. #12
    Benutzer
    Registriert seit
    20.11.2015
    Beiträge
    54
    @kk wäre es möglich dass die folgenden nginx.lua Änderungen mit in die nächste Version aufgenommen werden?

    Code:
     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

  3. #13
    Neuer Benutzer
    Registriert seit
    25.02.2019
    Beiträge
    4
    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

  4. #14
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.240
    Zitat Zitat von WolfgangS Beitrag anzeigen
    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?)

    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

  5. #15
    Neuer Benutzer
    Registriert seit
    25.02.2019
    Beiträge
    4
    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

  6. #16
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.240
    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

  7. #17
    LiveConfig-Team Avatar von kk
    Registriert seit
    10.12.2010
    Beiträge
    3.240
    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:
    Code:
    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. ;-)

  8. #18
    Neuer Benutzer
    Registriert seit
    25.02.2019
    Beiträge
    4
    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

  9. #19
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    680
    @kk: bitte den ersten Beitrag auf die neuen RewriteRule anpassen. Danke!

  10. #20
    Benutzer
    Registriert seit
    18.12.2012
    Beiträge
    96
    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?

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •