Rudi-Shell absichern

Hallo zusammen,

ich habe die Rudi-Shell etwas abgeändert:

Problem:
URL-Aufrufe.
Ich denke, die meisten wissen, was ich meine.

Lösung:
Wurde angehangen, in der Hoffnung, dass kein Exploit übersehen wurde.

Das war es auch schon.

EDIT:
Das Archiv wurde ausgetauscht. Die Änderungen von Whoopie habe ich in die Patches miteinfließen lassen.

Hi,

ich muss zugeben, das ich etwas Patchfaul war.
Sozusagen erfüllt das hier den zweiten Teil des Tickets. Ich werde morgen nochmal einen Patch posten in Ticket #294 mit beiden Änderungen

Whoopie schrieb:

bei mir funktioniert's leider nicht. Ich musste in rudi_shell.cgi den Befehl " cat << EOF " in " cat << 'EOF' " ändern, damit überhaupt die Rudi-Shell angezeigt wird.

Zum Vergrößern anklicken....

Mhh.... also bei mir funktionieren beide Varianten. Ich hatte mit FF unter Windows, wie auch unter Ubuntu getestet. Die busybox-Versionen dürften sich doch nicht unterscheiden, oder?

Whoopie schrieb:

Könntest Du die Rückmeldung "Security failed" dann auch noch internationalisieren?

Zum Vergrößern anklicken....

Wollte ich machen, jedoch funktioniert die Internationalisierung bei 'rudi_shellcmd.cgi' nicht (fwmod übergeht die Datei). Hab es deswegen erstmal auf Englisch gelassen.

Ich hab die Patches in Ticket #294 geposted und deine Änderungen übernommen. Jedoch habe ich die Interpreterzeile '#!/usr/bin/haserl -u 10000 -U /var/tmp' aus deinem Patch rausgenommen. Nicht, dass dies der Grund für die leere Seite war...

Danke. Ich wusste, dass ich mir die Datei doch hätte anschauen sollen.

EDIT:
Nun auch mit .language Patch. Zudem wird geprüft, ob die Datei /var/run/rudi_shell.pid existiert.

Also bei mir ebenfalls busybox 1.12.3 (aus dem trunk). Falls nirgendwo ein Leerzeichen bei einem EOF vorkommt, bin ich etwas ratlos. Wie bereits gesagt wurde, wird der Inhalt zwischen den EOFs als Ausgabe verwendet. Am Anfang der Ausgabe muss auf jedenfall ein "Content-Type" gefolgt von zwei LFs erfolgen.

Aber cat << 'EOF' funktioniert bei mir auch. Müsste man den Patch nur etwas abändern.

Schon merkwürdig. Für mich kann das Ticket auf jedenfall geschlossen werden - auch wenn mir vorher nichtmal bewusst war, das solch ein Ticket existierte.

Interessante Sache. Wäre es nicht besser, der httpd-inetd verhält sich genauso wie der httpd-standalone?
Also, ohne stderr auszugeben?

In /usr/bin/webcfg:

Die Syntax des Skriptes ist ja nicht falsch ...

EDIT:
Nochmal geprüft mit httpd-standalone. stderr wird ebenfalls ausgegeben, jedoch auf der Konsole. Dabei wird aber nicht verhindert, dass die Webseite geladen wird.

Es dürfte an sich nichts mit der busybox zu tun haben sondern mehr mit dem inetd.

Im inetd-Mode wird stderr auf stdout umgeleitet, was die Webseite daran hindert zu laden. Der "Content-Type" kommt erst nach der Fehlermeldung.

Klar sollte man hier "cat << 'EOF'" schreiben, wenn dabei ein Fehler entsteht (warum auch immer). Es ändert jedoch nichts daran, das httpd-standalone und httpd-inetd sich unterschiedlich verhalten.