Rudi-Shell absichern

bodega · 6 Jan 2009

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.

olistudent · 6 Jan 2009

Hi Marco,
schön dass du dich der Sache angenommen hast.

Warum hast du kein Patch angehängt?

MfG Oliver

meiser79 · 6 Jan 2009

Hi,

Könntest Du meinen Patch aus http://www.freetz.org/ticket/294 berücksichtigen? Was hältst Du von ihm?

Ich häng mal ein diff an zum besseren Drüberschauen. Der eigentliche Patch müsste dann gegen die Dateien in root/usr/mww/cgi-bin sein, bevor die Spracheinstellungen durchgeführt werden.

Beste Grüße,
Whoopie

bodega · 6 Jan 2009

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

meiser79 · 6 Jan 2009

Hi,

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.

Aber wenn ich nun was eingebe, sehe ich keine Auswirkung. Ich teste mit FF 3.0.5 unter Ubuntu Hardy und WinXP.
Ich sehe ne PID in /var/run/rudi_shell.pid. Wie kann man das debuggen?

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

Beste Grüße,
Whoopie

bodega · 7 Jan 2009

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.

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?

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...

Silent-Tears · 7 Jan 2009

Hast du das File auch in freetz-dir/.language eingetragen?

bodega · 7 Jan 2009

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.

meiser79 · 8 Jan 2009

Also bei mir geht es nur mit " cat << 'EOF' ". Mit FF unter Ubuntu und WinXP.

Welche busybox-Version nutzt Du? Ich bin auf aktuellem Trunk mit busybox 1.12.3.

Silent-Tears · 8 Jan 2009

Es sollte keinen Unterschied machen, welchen Client man nutzt, so lang irgendwie (x)html auftaucht beim Clientbrowser.

RalfFriedl · 8 Jan 2009

Whoopie schrieb:
den Befehl " cat << EOF " in " cat << 'EOF' " ändern,

Der Unterschied zwischen EOF und 'EOF' liegt darin, wie der Text zwischen cat und EOF behandelt wird. Ich vermute nicht, daß der verwendete Browser einen Unterschied macht, es sei denn, die unterschiedliche Ausgabe bei EOF und 'EOF' wirkt sich beim einen Browser anders aus als beim anderen.

bodega · 8 Jan 2009

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.

meiser79 · 8 Jan 2009

Ok, nichts desto trotz krieg ich keine Ausgabe, wenn ich einen Befehl ausführe.

bodega · 8 Jan 2009

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.

meiser79 · 9 Jan 2009

Also die Fehlermeldung bei Benutzung von "cat << EOF" lautet, und zwar das in Zeile 52:

Code:

cat: can't open ' + file + ': No such file or directory

EDIT: Hab jetzt rausgefunden, dass es daran liegt, dass ich den httpd über inetd starten lasse. Im standalone-Mode geht es.

RalfFriedl · 9 Jan 2009

Das ist aber sehr seltsam.
Hast Du noch eine Version, wo es Probleme mit den integrierten Applets gab?
Was passiert bei "echo << EOF" ?

bodega · 10 Jan 2009

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:

Code:

...
exec $DAEMON "$@" -p "$MOD_HTTPD_PORT" -c /mod/etc/$DAEMON.conf -h "$homedir" -r "Freetz (user:admin)" [COLOR="Red"]2>/dev/null[/COLOR]

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.

meiser79 · 11 Jan 2009

RalfFriedl schrieb:
Hast Du noch eine Version, wo es Probleme mit den integrierten Applets gab?

Nein, ich bin auf aktuellem freetz-trunk mit allen Patches für die busybox, die dieses Problem doch beheben sollten.

RalfFriedl schrieb:
Was passiert bei "echo << EOF" ?

Da sieht die Ausgabe so aus:

Code:

cat: can't open ' + file + ': No such file or directory
HTTP/1.0 200 OK

D.h. echo wirft garnix aus, alles, was zwischen "echo << EOF" und EOF steht, wird nichtmal angezeigt.

bodega · 11 Jan 2009

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.

Rudi-Shell absichern

Aktives Mitglied

Anhänge

IPPF-Urgestein

Aktives Mitglied

Anhänge

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

Aktives Mitglied

IPPF-Promi

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Statistik des Forums