Heute morgen wurde bei einem Upgrade auf einem Debian-Server u.a. auch Piwik aktualisiert, und zwar auf die Version 2.16.3. Das Update lief ordentlich durch, aber das Backend von Piwik war danach nicht mehr zu gebrauchen: viele Icons konnten nicht mehr geladen werden. Firebug verriet, dass der Webserver statt der Bilder lauter 500 „Internal Server Errors“ auslieferte.
Ein Blick in das Error-Log des Apachen zeigte folgende Fehlermeldungen:
/usr/share/piwik/plugins/.htaccess: AddHandler not allowed here
Diese .htaccess Datei wurde durch das Update aktualisiert und enthielt seitdem wohl auch eine AddHandler Direktive, die durch die Konfiguration des betreffenden VirtualHosts aber nicht erlaubt war. Die AllowOverride Direktive war hier zu restriktiv:
AllowOverride Limit
Nachdem ich diese auf „All“ abgeändert und den Server neu geladen habe, läuft Piwik wieder ordnungsgemäß.
Update 2 Das „AllowOverride All“ setzt die Sicherheit deutlich herab (siehe hierzu auch die Kommentare von Marius). Man sollte maximal „AllowOverride AuthConfig Limit FileInfo“ verwenden. Noch Sicherer ist es, die restriktive Einstellung „AllowOverride Limit“ (bzw. „AllowOverride AuthInfo“ für Apache 2.4) zu belassen, und diesen Abschnitt aus der Datei /usr/share/piwik/plugins/.htaccess zu löschen oder auszukommentieren und stattdessen in die VirtualHost-Konfiguration zu schreiben:
<IfModule mod_mime.c>
AddHandler text/html .html
AddHandler text/html .htm
</IfModule>
Man muss diesen Schritt dann bei jedem Piwik-Update, bei welchem die .htaccess Datei überschrieben wird, wiederholen.
Update 1
Ich habe jetzt auch einen Bug-Report eingereicht:
https://github.com/piwik/piwik/issues/10672
Die Ursache des Problems lag m.E. eher bei den restriktiven Einstellungen des Webservers, aber es wäre vielleicht nicht verkehrt, wenn die Anforderungen seitens piwik dokumentiert werden.
Kommentare
Wäre es nicht sicherer die AddHandler Direktive direkt in die vhost Config zu schreiben?
Im Prinzip schon – allerdings wäre dies nicht update-sicher. Wenn Piwik bei folgenden Updates diese .htaccess Datei überschreibt, habe ich jedesmal wieder ein kaputtes Backend und muss das manuell fixen.
Hello, thanks for writing about this. As it sounds like a bug in Piwik, it would be great to create a bug report on our tracker at: https://github.com/piwik/piwik/issues
we would really appreciate and like to fix this issue for all users automatically
I have not considered this as an bug in piwik as the option „AllowOverride Limit“ from my webserver was too restricted; but I will write an bug report that it could be perhaps mentioned in the „required configuration“ that the file /usr/share/piwik/plugins/.htaccess needs the option „AllowOverride All“
I have submitted this bug report:
https://github.com/piwik/piwik/issues/10672
Herzlichen Glückwunsch,
Sie haben grade Ihren Webserveraccount für Hacker interessant gemacht.
Wenn man solche Directiven in der htaccess erlaubt, kann ein Angreifer mit Zugriff auf das Filesystem, den kompletten Server übernehmen.
Um genau das zu verhindern, sind die Directiven von Apache so, auch wenn die immernoch zuviel erlauben.
Ergebnis der Aktion: auch das letzte Quentchen Sicherheitsmaßnahme des Webserver ist abgeschaltet worden.
Beispiel:
mach mal in einem Account
ln -s /etc/passwd {PFAD Zum DocRoot)/passwordliste.txt
ln -s / {PFAD Zum DocRoot)/root
in der .htaccess passend dazu Symlinks ohne gleiche Inhaber erlauben… ups.. owned.
AddHandler erlaubt z.b. .html Datei als PHP auszuführen, das ist praktisch, aber er erlaubt auch, irgendein anderes Executeable auszuführen. Das erlaubt das Abschalten von (Fast)CGI Wrappern => schwere Sicherheitslücke. Die sorgen z.b. dafür, nichts als der Apacheuser auszuführen. Weil, WENN man das kann, kann man auch Files des Apache ändern und den Webserver neustarten. Wenn man Files ändern kann, die mit +s auf Root ausgestattet sind .. den Gedanken muß ich wohl nicht weiter ausführen,oder ?
Wenn ich apache bin, arbeite ich auch außerhalb der Chroot (Du hast doch eine Chroot im CGIWrapper drin ODER ?!?!?! ), d.h. ich kann aufgrund der laschen Userrechte der meisten Linux Distros mehr sehen, als ich sollte!
Klar was ich damit sagen will ?
AddHandler HAT NICHTS … GAR NICHTS! … in irgendeiner Anwendung in irgendeiner .htaccess verloren.
Fazit:
Wenn eine Anwendung „AllowOverride All“ benötigt: LÖSCH SIE!
Wenn eine Anwendung „AllowOverride All“ benötigt: LÖSCH SIE!
Es gibt eine Menge Anwendungen, die das erfordern – so erfordert mod_rewrite in der .htaccess Datei genauso wie die AddHandler-Direktive ein „AllowOverride All“ bzw. „AllowOverride FileInfo“. WordPress beispielsweise nutzt mod_rewrite, wenn „benutzerdefinierte URL-Strukturen“ definiert werden, und schreibt mod_rewrite Code in die .htaccess Datei. Die Einstellung „AllowOverride All“ ist von daher bei vielen Webhostern schon recht verbreitet. Das soll jetzt aber nicht die Sicherheitsbedenken beiseite wischen.
ein Angreifer mit Zugriff auf das Filesystem
Ein Nachbar auf dem Server? oder das Update-Script von piwik, welches solche Symlinks setzt?
in der .htaccess passend dazu Symlinks ohne gleiche Inhaber erlauben
Das ist in dieser .htaccess Datei nicht der Fall, aber beim nächsten Update könnte piwik das natürlich rein schreiben, ohne dass man es bemerkt.
—
Ich habe den Beitrag oben mit einem Hinweis auf deinen Kommentar ergänzt
„All“ braucht man für Mod Rewrite nicht.
Da es heute ein extrem schönes Beispiel einer Schwachstelle gab, daß sich auch auf Webhostingumgebungen auswirken kann, habe ich Deinen Beitrag mit der Schachstelle verknüpft und einen Artikel fürs OSBN draus gemacht:
https://marius.bloggt-in-braunschweig.de/2016/10/04/cve-2016-7543-gravierende-schwachstelle-in-bash-4-4/
Ich hatte schon beim Schreiben gesehen, daß Du meinen Protest ernst genommen hast und in dem Artikel wird gleich klar werden, wieso das so wichtig ist.
Wenn man etwas der Welt präsentiert, kann man gar nicht paranoid genug sein. Jeden Tag prasseln hunderttausend Scanversuche auf die Server nieder, die alle nach der einen Lücke im Code suchen. Ist echt zum Kotzen. Manchmal ist die Rüstung so dünn, daß einem Schlecht wird, wenn man dran denkt.
Das mit den SymLinks ist leider eine DEFAULT Einstellung beim Apachen.
Pack das in Deinen Vhost rein :
Options -FollowSymLinks +SymLinksIfOwnerMatch
Das erlaubt Symlinks nur, wenn Ziel und Quelle dem selben Benutzer gehören. Damit kann man als Apache/wwwrun usw. keinen Link auf Sachen setzen, die ROOT gehören. Innerhalb der eigenen Anwendung geht das natürlich imemrnoch und da ist es ja auch legitim.
Und bitte, schaff Dir einen CGIWrapper an, der was taugt. Das hat diverse Vorteile, z.b. kann man die Laufzeit von Scripten so begrenzen, daß es keine Endlosschleifen gibt. Eine Chroot sollte auch Pflicht sein. Selbst wenn Deine Webanwendung eine Lücke hätte, so wäre lediglich Dein Webaccount kompromitiert, nicht gleich der ganze Server. Aus einer Chroot heraus kann man auch genug Ärger machen, aber, glaub mir, das Ding ist GOLD wert
Wenn Du weitere Fragen hast, kannste Dich direkt an mich wenden.
„All“ braucht man für Mod Rewrite nicht.
Ja, ich hatte ja auch geschrieben ‚bzw. „AllowOverride FileInfo“‘ :). Wenn ich die Dokumentation nicht fehlinterpertiere, dann reicht eben auch diese Einstellung schon (wie bei mod_rewrite), um AddHandler und Action Direktiven in der .htaccess Datei zu erlauben (?):
https://httpd.apache.org/docs/2.4/de/mod/core.html#allowoverride
Aber bei einem „AllowOverride AuthInfo FileInfo“ wäre (im Gegensatz zu „AllowOverride All“) die Direktive Options nicht inbegriffen, so dass man „Options -FollowSymLinks“ nicht mit der .htaccess Datei überschreiben kann.
Noch was zu den Symlinks:
Piwik ist in diesem Fall als Debian-Paket installiert und die Updates erfolgen nicht über das Webinterface, sondern über das Paketmanagement (aptitude). Das DocumentRoot verweist auf /usr/share/piwik welches root gehört – weder der Webserver noch ein anderer User können dort Symlinks setzen. Das Unterverzeichnis tmp (welches durch ein „Require all denied“ geschützt ist) ist allerdings für den Webserver beschreibbar. Und ein Update-Script von piwik, welches von dpkg mit root Rechten ausgeführt wird, kann natürlich im gesamten DocumentRoot-Verzeichnis beliebig Symlinks setzen.