Ein paar Einträge in die apache access.log bereiten mir Kopfzerbrechen

[Rolf B]

Hallo Claus,

ich habe deine Domain ersetzt.

Wenn Du vom Browser aus http://example.org/../foo/bar.dat oder http://example.org/foo/../../etc/hosts abrufst, wird das vom Browser schon normalisiert und kommt gar nicht beim Server an. Auch dann, wenn Du die Punkte als %2E maskierst. Das siehst Du in den Developer-Tools des Browsers.

Du musst das schon unverfälscht mit einem Tool wie wget oder mit einem manuell programmierten HTTP Request zum Server bringen, und da setzt der Exploit an.

Wenn der Server einen solchen Pfad vor Prüfung auf Zulässigkeit nicht normalisiert, und einfach nur das Directory Root mit dem vom Client kommenden Pfad verkoppelt, könnte dort ein Zugriffspfad wie

/usr/web/example.org/icons/foo/../../evil

entstehen. D.h. man läuft aus icons/foo hinaus und ist - vermeintlich - auf der Ebene von /usr/web/example.org. Dies scheint unverdächtig, wenn da nicht der Umstand wäre, dass icons Ordner vom Apache als Alias in jeden Web-Ordner hineingespiegelt wird. Warum?

In der httpd.conf steht:

# Fancy directory listings
Include conf/extra/httpd-autoindex.conf

Und in httpd-autoindex.conf steht

# We include the /icons/ alias for FancyIndexed directory listings.  If
# you do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "${SRVROOT}/icons/"

Directory Listings verhindert eigentlich jeder, und trotzdem ist dieser Alias für Icons fast überall aktiv.

Also: icons ist ein Ordner der Apache Installation, und ein falsch programmiertes System würde, wenn es erstmal in icons Ordner ist, mit ".." nach ${SRVROOT} kommen - dem Apache Installationsordner. Und wenn dieser Weg offen ist, hat man de facto Leserecht auf den ganzen Server.

Ich nehme an, dass diese Lücke früher mal bestand und aktuelle Indianer Dir eins mit dem Tomahawk geben, wenn Du den Exploit versuchst.

Rolf