Apache2 + cgi-script -> wie verhindern, dass #!/bin/bash genutzt wird

[kartoffelheinz]

Hallo,

ich habe ein kleines Sicherheitsproblem mit meinem Test-Webserver festgestellt.

Konfiguration:
Apache 2.2.3
SuExec2
auf Debian Etch

Wenn ich über "AddHandler cgi-script .pl" *.pl-Scripten die Möglichkeit gebe, als CGI-Script ausgeführt zu werden, gebe ich dem Skript gleichzeitig auch die Möglichkeit, nicht nur #!/usr/bin/perl als Interpreter, sondern auch #!/bin/sh oder #!/bin/bash usw. zu nutzen. Auch ohne dass der User eine Shell hat sind anscheinend Dinge wie

#!/bin/sh

px -aux >> /eine/datei/zu/der/user/schreibrechte hat.txt
ls -al /etc >> /noch/eine/datei/mit/schreibrechten.txt

möglich.

Sollte klar sein, dass ich das nicht will. Gibt es eine Möglichkeit, dem Apache irgendwie bevor er das Script an die entsprechende Binary weiterleitet die erste Zeile zu entfernen und z.b. bei *.pl immer #!/usr/bin/perl -w hinzusetzen? Oder kennt jemand eine andere Lösung? Ich würde es auch gerne über einen Wrapper laufen lassen, aber dafür müsste ich das dem Apache irgendwie mitteilen (wie?).

Schonmal Danke und Grüße
Florian

 

[Roger Wilco]

Inwiefern ist das ein Sicherheitsproblem? Die Skripte laufen jeweils dank SuExec als der Besitzer der Datei und alle Aktionen, die mit der Bash möglich sind, können auch mit Perl durchgeführt werden.

 

[kartoffelheinz]

Mh, das ist wohl richtig. Stellt das genannte Problem also keine Sicherheitslücke dar?

Wie sieht es damit aus, dass der User sich theoretisch durch die direktive "AllowOverride Fileinfo" z.B. für .php seinen eigenen FCGIWrapper setzen kann? Wäre das unter den gleichen Bedingungen eine Sicherheitslücke? Ich finde leider keine Möglichkeit, z.B. RewriteEngine zu erlauben und gleichzeitig das setzen von FCGIWrapper zu verbieten. Gibt es da etwas?

Grüße
Florian

 

[Roger Wilco]

Mh, das ist wohl richtig. Stellt das genannte Problem also keine Sicherheitslücke dar?

Wie schon geschrieben: Alles was mit der Bash möglich ist, geht auch mit Perl. Insofern würde dir das Verbieten von Bash-Skripten keinen Sicherheitsgewinn bringen, sondern eher in falscher Sicherheit wiegen.

Wie sieht es damit aus, dass der User sich theoretisch durch die direktive "AllowOverride Fileinfo" z.B. für .php seinen eigenen FCGIWrapper setzen kann?

Wenn du auf bestimmte Umgebungsvariablen angewiesen bist, die in deinen PHP-Wrappern gesetzt werden, dann eventuell, ansonsten ist das kein Problem, da die Skripte ja wiederum über SuExec als der jeweilige Dateibesitzer ausgeführt werden.

 

[kartoffelheinz]

Naja, ist schon blöd, dass jeder mit dem eigenen php-wrapper eine komplett eigene php.ini einsetzen könnte... gibts da einen weg drumrum?

 

[Roger Wilco]

Naja, ist schon blöd, dass jeder mit dem eigenen php-wrapper eine komplett eigene php.ini einsetzen könnte... gibts da einen weg drumrum?

mod_fcgid patchen, so dass FCGIWrapper nicht mehr im FileInfo/.htaccess Kontext genutzt werden kann. Ist im Prinzip nur eine minimale Änderung.

 

[kartoffelheinz]

Jau, das klingt nach einer Lösung. Vielen Dank!