Alexander (HH): Warum verlangen manche Software (Forum, Shop) 777'er Rechte

Beitrag lesen

Moin Moin!

Der Apache führt sie aber nur dann aus, wenn sie im CGI-Verzeichnis liegen. Das ist ein normales Verzeichnis, das mit Konfigurationsdirektiven (ScriptAlias) für die CGI-Ausführung freigegeben ist.
Das stimmt leider nur teilweise.
[andere Möglichkeiten]

Die setzen aber voraus, dass die irgendwer wissentlich oder versehentlich aktiviert. Ein (PHP-)Hoster wird das sicherlich nicht für die DocumentRoots der Kunden gemacht haben

Das sollte man jedenfalls hoffen.

Bleibt also Social Engeneering, sprich: evil bringe den technisch nicht so versierten User victim mit viel Text dazu, irgendwo eine passende .htaccess-Datei hinzupacken, x-Bits zu setzen, oder sich sonst irgendwie einen vorkonfigurierten Webserver zu verkonfigurieren. Das ist dann aber schon wesentlich gezielter als einfach auf dem Shared Hosting Webserver mit dem eigenen Account in der Verzeichnis-Nachbarschaft herumzuschnüffeln.

  • davon war ich für diesen Einwand ausgegangen. Wenn man davon ausgeht, können die x-Bits im Apachen nicht wirken. Wer sie allerdings für irgendwelche Zwecke aktiviert hat, sollte sich fragen, ob das wirklich im DocumentRoot notwendig muss.

Vollkommen richtig.

HTML und ein Shell-Script zu mischen sollte durchaus möglich sein, die große Kunst ist eigentlich nur, den HTML-Shell-Hybriden dann auch noch valide zu halten.

HTML-Validität wäre mir als Angreifer egal, Hauptsache ich bekomme die Syntax so hin, dass sie meinen Wunsch ausführt. Du meintest vermutlich syntaktische Validität.

Nö, ich meinte als Bonus oben drauf auch noch valides HTML, idealerweise sogar so, dass das Dokument auf den ersten Blick auch nicht nach einem Shell-Script aussieht. Technisch ist das natürlich nicht notwendig, gängige Browser akzeptieren meine primitive Demonstration ohne Murren.

Wenn der Script-Interpreter PHP heißt, dann braucht der kein x-Bit.

Doch, wenn PHP vom Betriebssystem via Shebang als Interpreter für ein Script geladen werden soll, muß das x-Bit gesetzt sein, sonst bekommt man errno=EPERM (Permission denied), unabhängig davon, ob es um PHP oder irgendeine andere interpretierte Sprache geht.

Da das das haupsächliche Einsatzgebiet von PHP-Scripten ist, ging ich an dieser Stelle von vom Apachen/Webserver gestarteten Scripten aus. Dafür sind keine x-Bits notwendig.

Der feine Unterschied ist, dass bei vielen Hostern und vielen Linux-Distributionen PHP gleich automatisch per mod_php in den Apachen eingebunden ist, während andere Sprachen via CGI oder seltener FastCGI angebunden werden. Deswegen scheint auf den ersten Blick PHP ein Sonderfall zu sein. Ist es aber nicht.

Auch vom Apachen via (F)CGI gestartete PHP-Scripte benötigen kein x-Bit, da der Apache das Script nicht via Shell sondern den PHP-Interpreter startet, der das Script als Parameter übergeben bekommt und dann nur noch das r-Bit braucht.

Fast richtig. Die Shell hat mit der ganzen Geschichte nichts zu tun, es sei denn, der Programmierer hatte einen sehr faulen Tag und noch nie etwas von Injection gehört.

Entweder hat der Webserver auf irgendeine Art Zugang zu einem dauerlaufenden Interpreter (mod_php, PHP als FastCGI), dann kann er über einen privaten Kanal (Funkionsaufruf, FastCGI-Request) den Interpreter anweisen, eine Datei zu laden. Dann reicht das r-Bit.

Oder der Webserver hat keinen solchen privaten Kanal und keinen dauerlaufenden Interpreter, oder kann/darf/will den Dauerläufer nicht nutzen, dann muß er ein CGI-Programm oder einen FastCGI-Server via exec() starten, und in beiden Fällen ist das x-Bit notwendig. Ist das CGI-Programm bzw. der FastCGI-Server ein Script, ist außerdem das r-Bit notwendig.

Klar, es schadet nicht, wenn ein Programm nicht ausführbar ist. chmod a-x /sbin/init && reboot, danach sprechen wir uns wieder ... ;-)

Wenn die Funktionalität benötigt wird, dann muss selbstverfreilich das x-Bit vorhanden sein. Das heißt jedoch nicht, dass alle Programme immer und zwingend das x-Bit brauchen, wenn sie nur mal eben irgendwo rumliegen sollen. Sowas soll ja auch gelegentlich vorkommen, dass man einen Teil des Dateisystems als Ablage und nicht als Ort zum Starten von Programmen verwendet. Beispielsweise, wenn man ein Programm uneingepackt (warum auch immer) zum Download anbietet, ist es nicht nötig, dass es aus dem Download-Verzeichnis heraus gestartet werden können muss.

Richtig. Dafür gibt es mount -o noexec, dann scheitert exec() trotz gesetzten x-Bits mit EPERM (Permission denied). Das verhindert allerdings nicht, dass man ein dort gelagertes Script per /usr/local/bin/interpreter /mnt/noexec/script gestartet wird. Binaries lassen sich aus einem mit noexec gemountetem Verzeichnis nicht starten.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".