Sicherheitsaspekte beim Einsatz von gzip_cnc
Die CGI-Schnittstelle eines Apache-Handlers
Wie der Beschreibung der Programmlogik zu entnehmen ist, wertet gzip_cnc im Wesentlichen den Inhalt der beiden Environment-Variablen
PATH_INFO(der URL-Pfad der angeforderten Datei) undPATH_TRANSLATED(der Dateiname der angeforderten Datei nach Übersetzungen durch Apache-Mechanismen)
aus. Beide werden vom Apache-Server mit den entsprechenden Werten belegt, wenn eine über die Apache-Direktive Addhandler eingebundene CGI-Anwendung aktiviert wird.
Der eigentliche Zugriff auf die angeforderte Datei unterliegt zuvor den normalen Sicherheitskonzepten des Apache-Servers. Zwei Beispiele hierfür seien genannt:
- expliziter Zugriffsschutz durch die Konzepte der Apache-Module
mod_accessbzw.mod_auth - impliziter Zugriffsschutz durch die Apache-Direktive
ScriptAlias(der Inhalt eines so definierten CGI-Verzeichnisses wird immer als CGI-Anwendung behandelt, nicht aber an den Client ausgeliefert)
Erst nach diesen Überprüfungen wird gzip_cnc als Handler gestartet und greift nun ohne weitere Prüfungen direkt auf den Inhalt der angeforderten Datei zu. Das es nur ein CGI-Skript ist, kennt es nicht die vollständige Apache-Konfiguration - es muß sich also darauf verlassen, daß der Apache-Server seine Arbeit in dieser Hinsicht bereits erledigt hat.
Und gäbe es keine andere Möglichkeit, gzip_cnc mit den entsprechenden Informationen zu versorgen, dann wäre dies auch ausreichend ...
Das Problem von gzip_cnc 1.10 und vorherigen Versionen
... leider gibt es aber diese Möglichkeit. Ein via AddHandler eingebundenes CGI-Skript ist immer noch ein CGI-Skript.
Und wenn man ein CGI-Skript aufruft und den Pfad einer weiteren auf diesem Server existierenden Datei an den URL anhängt - nicht als Query-String, sondern direkt als Pfadname, als ob das CGI-Skript ein Verzeichnis wäre! - dann verhält sich der Apache-Server fast genauso, als wäre diese andere Datei angefordert und das CGI-Skript als Handler dafür definiert worden. Die Anforderungen von
/index.htmlüber den definierten Handler/cgi-bin/gzip_cnc.plund/cgi-bin/gzip_cnc.pl/index.html(!)
sehen aus der Sicht von gzip_cnc.pl in allen bisher behandelten Aspekten absolut identisch aus.
Tatsächlich realisiert der Apache-Webserver diese Handler-Einbindung intern durch eine Weiterleitung auf genau diesen URL, wie man selbst überprüfen kann: Wenn einer solchen Handler einen Fehler verursacht, wird der so zusammengesetzte URL zusammen mit der Fehlermeldung im Browser angezeigt.
Es gibt allerdings einen entscheidenden Unterschied zwischen beiden Aufrufen:
- Im ersten Fall prüft der Apache-Webserver die Berechtigung des Besuchers für den Zugriff auf den URL
/index.html, - im zweiten Fall dagegen die Berechtigung für den Zugriff auf den URL
/cgi-bin/gzip_cnc.pl!
Auf diese Weise bildete gzip_cnc bis Version 1.10 unabsichtlich einen Tunnel durch sämtliche vorhandenen Sicherheitsmechanismen des Apache-Webservers, weil der Server nicht merkte, daß der Besucher eigentlich auf eine ganz andere Datei zugreift. Das CGI-Skript merkte seinerseits nicht, daß vor seinem Aufruf gar keine Zugriffskontrolle für die eigentlich angeforderte Datei statt gefunden hat. Jeder der beiden verläßt sich auf den anderen.
Und das Ergebnis ist fatal: Wenn ein Angreifer den URL eines installierten gzip_cnc.pl-Skripts erraten hat, dann kann er jede Datei innerhalb des URL-Raums lesen.
Erkennen des direkten Zugriffs durch gzip_cnc
Aber wie kann gzip_cnc einen Unterschied bei zwei nahezu identischen Aufrufen erkennen? Die Apache-Dokumentation liefert anscheinend keine zuverlässige Methode dafür.
Meine eigenen Experimente mit verschiedenen Apache-1.3.x-Versionen haben ergeben, daß der Inhalt der Environment-Variable REDIRECT_URL in diesen beiden Fällen anscheinend unterschiedlich gesetzt wird:
- Bei einem impliziten Zugriff über den Handler enthält diese Variable denselben URL wie
PATH_INFO, - bei einem expliziten Zugriff auf das CGI-Skript jedoch den URL des CGI-Skripts.
Wobei die Tatsache, daß sogar der direkte Zugriff auf das CGI-Skript einen Wert für diese REDIRECT_URL-Variable verursacht, zu bedeuten scheint, daß auch das Abtrennen des 'überschüssigen' Teils des URL vom Apache-Server durch eine interne Weiterleitung realisiert wird.
Obwohl dies keine offiziell dokumentierte Information ist, habe ich in gzip_cnc 1.11 die hier beschriebene Prüfung zusätzlich eingebaut. gzip_cnc vergleicht die Werte der beiden Environment-Variablen PATH_INFO und REDIRECT_URL und weist die Anforderung mit dem HTTP-Status 403 und einer kurzen Fehlermeldung zurück, falls sie nicht identisch sind.
Bei Tests mit zwei Apache-Versionen (1.3.12 und 1.3.26) lieferte diese Änderung die erwünschte Unterscheidung - ich möchte aber ausdrücklich klarstellen, daß ich für sämtliche Apache-Versionen keine allgemeingültigen Aussagen treffen kann.
Überprüfung von gzip_cncs Zugriffskontrolle durch den Anwender
Deshalb sollte jeder gzip_cnc-Anwender unbedingt prüfen, ob dieser Test bei seiner Installation die gewünschte Wirkung hat. Dazu eignet sich vermutlich am besten der Versuch, den Inhalt eines installierten CGI-Skripts zu lesen (denn genau das sollte normalerweise vom Apache-Server verhindert werden) - beispielsweise den Quelltext von gzip_cnc selbst, durch eine Anforderung eines URL der Art /cgi-bin/gzip_cnc.pl/cgi-bin/gzip_cnc.pl.
Sollte in diesem Falle auch gzip_cnc 1.11 noch seinen eigenen Inhalt anzeigen, dann empfehle ich dringend, gzip_cnc in Deinem Webspace nicht zu verwenden. Aber auch für den Fall, daß diese Prüfung erfolgreich ist, möchte ich klarstellen, daß der Einsatz eines fremden Programms immer auf eigenes Risiko erfolgt ...
(Michael Schröpl, 2002-09-08)