Hallo, Ratti:

...

ich möchte auf meinem apache einige cgi-scripte verwenden, die tief ins System eingreifen und daher root-Rechte benötigen.

Bernd Brodesser:

man sudo man sudoers man su1

Na, wie geschrieben: Das langt nicht... Siehe unten.

Das SUID und auch das SGID Bit funktioniert nicht bei Skripten, sondern nur bei Programmen.

SCH.... Gibt es eine Möglichkeit, das zu umgehen? Weil:

...

Übrigens wird "sudo" mein Problem nicht lösen. Wieso nicht? sudo muß natürlich im Skript stehen.

Das dürfte nicht langen. Die cgis, die ich installieren will, sind für die Rechneradministration gedacht, enthalten komplette Webmailsystem usw... Der root-Zugriff wird nicht nur benötigt, indem man mal eben das Starten von $BEFEHL per sudoers.conf erlaubt. Es muss auch, beispielsweise, mit open-Befehlen auf die Postfächer aller User zugegriffen werden können und dergleichen. Also echter, voller, unbeschränkter rootzugriff. Das ist mit sudo&Co. doch nicht möglich, wenn ich das richtig begriffen habe. Da lassen sich nur einzelne Befehle freigeben. Wer hat sich diese beknackte Beschränkung der Skripte ausgedacht? Für normale Kommandozeile könnte ich ja noch ein kurzes C-Gerüst davor hängen, dann wäre es ein Binary, das einen Shell-Befehl absetzt. Aber für ein cgi kommt ja die ganze Ausgabeumleitung dazu. Außerdem verweigert das cgi sowieso den Start, weil es überprüft, ob es geSuid-ed wurde.... Gibt es eine Möglichkeit, die Beschränkung zu umgehen? Das heisst, ja, daß bis auf webmin, das einen eigenen Webserver verwendet, der als root läuft, keines der gängigen webbasierenden Verwaltungssysteme auf einem Suse-System läuft? Autsch. Grummel. Wenn ich ein OS gewollt hätte, das mich am Patschehändchen nimmt, hätte ich mir einen Mac gekauft... Gruß, Ratti

Hallo, Ich werde mir dieses suidperl aus Konrads Mail mal angucken. Dies hier nur noch mal zur Klärung/Komplettierung: Bernd Brodesser:

Was verstehst Du unter open-Befehle? Ich kenne open nur als ein Systemaufruf. Oder bei perl. Wenn Du vor jedem Befehl ein sudo setzt, dann müßte es meiner Meinung nach doch gut sein, oder etwa nicht?

Genau, also Systemaufruf. Per sudo könnte ich m.E. den Zugriff auf sagenwirmal ipchains freigeben oder dergleichen. Aber was ist mit sowas (in perl): open LESEN , "< /var/spool/mail/root"; Da würde mir sudo nicht helfen. Mal ganz abgesehen davon, daß es sich um mehrere hundert Kilobyte Scripte handelt, die für suidroot programmiert sind, und ich mehrere dieser Systeme ausprobieren möchte. :%-) -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows

Ratti schrieb:

Ratti:

...

...

ich möchte auf meinem apache einige cgi-scripte verwenden, die tief ins System eingreifen und daher root-Rechte benötigen.

cgi-scripte? Was für Scripte verwendest Du denn da? Zu jedem Script gehört IMHO ein Interpreter. CGI-Script bedeutet IMHO einfach nur, dass es ein Script ist, welches eine bestimmte Schnittstelle nutzt.

Bernd Brodesser:

...

man sudo man sudoers man su1

Na, wie geschrieben: Das langt nicht... Siehe unten.

Jein. Das langt fast. Wenn Du z.B. ein Perl-Script nutzt, dann kannst Du einen Perl-Wrapper nutzen. Da gibt es z.B. ein suidperl. Dieses suidperl hast setuid root und läuft daher als root-User. Und es checkt, ob das Script auch ein solches suid-Flag hat. Somit kannst Du Dir einen einfachen Wrapper schreiben, egal was Du verwendest.

Die cgis, die ich installieren will, sind für die Rechneradministration gedacht, enthalten komplette Webmailsystem usw...

Wer hat sich diese beknackte Beschränkung der Skripte ausgedacht? Das waren Leute, die Ahnung von Security haben.

Für normale Kommandozeile könnte ich ja noch ein kurzes C- Gerüst davor hängen, dann wäre es ein Binary, das einen Shell- Befehl absetzt. Aber für ein cgi kommt ja die ganze Ausgabeumleitung dazu. Außerdem verweigert das cgi sowieso den Start, weil es überprüft, ob es geSuid-ed wurde....

Gibt es eine Möglichkeit, die Beschränkung zu umgehen?

Das heisst, ja, daß bis auf webmin, das einen eigenen Webserver verwendet, der als root läuft, keines der gängigen webbasierenden Verwaltungssysteme auf einem Suse-System läuft? Autsch. Wieso denn das? Siehe oben!

Ich nutze z.B. open-webmail. Dies sind Perl-scripte, die tatsächlich mittels suidperl zu Ihren root-Rechten kommen. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

Hallo,

...

Wer hat sich diese beknackte Beschränkung der Skripte ausgedacht?

Thomas Schubert:

Google mal ein wenig herum, ich hab mal eine Aufzählung von Gründen gesehen, wie man ein Skript superleicht mit Umgebungsvariablen etc ausnützen kann bzw mißbrauchen. Mit einem suid Skript ist das echt schlecht ...

Das glaube ich gerne. Es geht hier aber um zwei Systeme, die kein User in dem Sinne haben. Zunächst mal mein Server zuhause, auf dem ich mir einige administrative Erleichterungen installieren will und auch größere Projekte testen, Groupware, Webmailer und so. Wenn das so funktioniert, kommt ein Teil davon auf meinen Arbeits-Server. Auch dort gibt es die User nur administrativ, niemand loggt sich ein (Erstens kann's keiner, und zweitens haben sie keine Shell) Wenn mir also jemand was auf die Platte legen wollte, müsste er einbrechen. Da gebe ich mich auch keiner falschen Sicherheit hin: Ich murkel seit gerademal 1,5 Jahren an Linux rum, und wenn ein Profi in mein System reinwill, dann schafft er das auch. Aber ohne zu murkeln komme ich eben auch nicht mit dem Lernen weiter. Gruß, Ratti -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows

Moin, David Haller:

Du willst unbedingt den -T switch verwenden (s. 'man perlrun' und 'man perlsec'):

Ganz sicher will ich den nicht verwenden. Darum ging es ja die ganze Zeit: cgis den _vollen_ Zugriff auf das System zu ermöglichen, und eben aus administrativen Gründen eben auf die interessanten Bereiche. Sprich: Ich will per cgi machen können, was ich als root in der Bash machen kann. Passwörter ändern und dergleichen.

use strict;

Ne, das nörgelt mir zuviel an. Gruß, Ratti

Hallo, On Fri, 05 Apr 2002 at 22:53 (+0200), David Haller wrote:

On Fri, 05 Apr 2002, Ratti wrote:

...

David Haller:

...

Du willst unbedingt den -T switch verwenden (s. 'man perlrun' und 'man perlsec'):

Ganz sicher will ich den nicht verwenden.

Oh doch. Gerade bei cgis!!!

ACK! Ich verwende ihn eigentlich nur bei CGIs.

...

Darum ging es ja die ganze Zeit: cgis den _vollen_ Zugriff auf das System zu ermöglichen, und eben aus administrativen Gründen eben auf die interessanten Bereiche.

Das geht auch mit -T.

ACK. -T ist ja nicht vorhanden, um die Zugriffrechte zu beschränken sondern um zu verhindern, dass das Skript durch falsche Parameter angreifbar ist (mal ganz salopp ausgedrückt).

...

...

use strict;

Ne, das nörgelt mir zuviel an.

Aus gutem Grund!!!

ACK. Wenn man bewusst Dinge verwenden will, die use strict; nicht ermöglicht, kann man es ja für einen engen Bereich ausschalten, z. B. #!/usr/bin/perl -wT use strict; our $irgendwas = "TEST"; my $varname = "irgendwas"; { no strict 'refs'; # Verwendung von symb. Referenzen einschalten print ${$varname}; # Symbolische Referenz; Zugriff auf $irgendwas } Sicher ist das hier jetzt an den Haaren herbeigezogen, aber es gibt doch durchaus einige (wenige) Fälle, wo man symbolische Referenzen gut gebrauchen kann. Siehe auch: Seite 883 "Programmieren in Perl". (Habe nämlich selber schnell nachschauen müssen, weil ich mir mit der Syntax nicht mehr zu 100 % sicher war.) Gruß, Bernhard -- "The last good thing written in C was Franz Schubert's Symphony No. 9." -- Werner Trobin

Moin Moin, Am Samstag, 6. April 2002 12:46 schrieb Ratti:

...

...

David Haller: Ganz sicher will ich den nicht verwenden.

Oh doch. Gerade bei cgis!!!

Oh Nein. Gerade da nicht. ;-)

Zitat von Larray Wall aus Programmieren mit Perl 3.Ausgabe: "Wenn Sie ihre CGI-Skripten aber nicht im Taint-Modus ausführen, verzichten Sie unnötig auf den größten Schutz, den Perl Ihnen bieten kann." [...]

Das verstehe ich inzwischen, es deckt sich mit einer Anmerkung aus perlsec:

Perl automatically enables a set of special security checks, called taint mode, when it detects its program running with differing real and effective user or group IDs.

Heisst im Klartext: -T ist per default aktiviert!

Besser ist es trotzdem "-T" zu verwenden:)

Deswegen ging mein Script auch nicht auf Anhieb.

Die Situation ist die, daß es sich um _ausschliesslich_ meinen Server handelt. Niemand anders packt da Scripte drauf als ich, und jede Einschränkung stört mich.

Offenishctlich ist also der Taint-Modus aktiv, und das will ich nicht. Weisst du /jemand, wie man das loswird?

Warum? Wer im 21. Jahrhundert nicht an die Sicherheit denkt, wird nix mehr! SCNR

Ich will in meinen cgi's einschränkungslos alles amchen können, was ich auch tun kann, wenn ich mich per ssh zu root hochge-su'ed habe.

sudo ?

...

Eben. Und genau deswegen sollten die cgis sicher programmiert sein, und genau dabei hilft -T (und strict). Sonst kann einer a la Nimda daherkommen und dann als root was ausfuehren...

ACK, siehe BugTraq!

Das ausbrechen aus dem Pfad (Nimda) verhindert Apache. Die Sicherheit meiner Scripte möchte ich gerne selbst implementieren, ohne daß das System mir Knüppel vor die Füße wirft.

Warum dann keinen Taint-Modus, der nimmt Dir doch 'ne Menge ab??

Ich bin in der Hinsicht ziemlich geschädigt. Ich habe massenweise Projekte über Bord werfen dürfen, die fast fertig waren, weil sich irgendwann an einer eigentlich nebensächlichen Stelle herausstellte, daß irgendwas, was in der Bash geht, cgis wieder nicht erlaubt ist. Das hört auf. ;-)

Was kannst Du den nicht machen mit dem Taint Modus?

...

...

...

use strict;

Ne, das nörgelt mir zuviel an.

Aus gutem Grund!!!

Nö. Variablendeklaration und -initialisierung und dergleichen will ich im 21. Jahrhundert nicht mehr sehen, das hat mein Interpreter/Compiler zu erledigen.

Hmm, Java z.B. ist eine der neusten Sprache (auch, wenn ich C++ besser finde!!). Selbst dort mußt Du variablen deklarieren und initialisieren. Übrigens muß jede Variable irgendwann mit etwas initialisiert werden, oder habe ich da etwas verpaßt!?

Wer einmal BASIC gelernt hat, aus dem wird nix rechtes mehr. ;-)

Ja, aber nur wenn er nichts neues lernt:) Ein schönes Wochenende allen. ByE Andre

Hallo, On Sun, 07 Apr 2002, Bernhard Walle wrote:

On Sat, 06 Apr 2002 at 19:17 (+0200), Andre Heine wrote:

...

Am Samstag, 6. April 2002 12:46 schrieb Ratti:

...

...

...

David Haller: Ganz sicher will ich den nicht verwenden.

Oh doch. Gerade bei cgis!!!

Oh Nein. Gerade da nicht. ;-)

Zitat von Larray Wall aus Programmieren mit Perl 3.Ausgabe:

"Wenn Sie ihre CGI-Skripten aber nicht im Taint-Modus ausführen, verzichten Sie unnötig auf den größten Schutz, den Perl Ihnen bieten kann."

*dick unterstreich*

*doppelt unterstreich*

...

...

Ich bin in der Hinsicht ziemlich geschädigt. Ich habe massenweise Projekte über Bord werfen dürfen, die fast fertig waren, weil sich irgendwann an einer eigentlich nebensächlichen Stelle herausstellte, daß irgendwas, was in der Bash geht, cgis wieder nicht erlaubt ist. Das hört auf. ;-)

Dann hast du was falsch (=unsauber) gemacht.

...

Was kannst Du den nicht machen mit dem Taint Modus?

Frage ich mich auch.

Dito.

...

...

...

...

...

use strict;

Ne, das nörgelt mir zuviel an.

Aus gutem Grund!!!

Nö. Variablendeklaration und -initialisierung und dergleichen will ich im 21. Jahrhundert nicht mehr sehen, das hat mein Interpreter/Compiler zu erledigen.

Dann nimm halt nicht perl. Du kannst dir z.B. auch mit der bash, csh, tk, C oder C++ (oder Java?) cgis schreiben, um dir in den Fuss zu schiessen. Haelt dich niemand davon ab. Aber perl ist so nett und bietet dir die Bequemlichkeit, dich auf deine Fehler aufmerksam zu machen... [..]

Manchmal hat sogar eine Typenunterscheidung (wie in C/C++ oder Java) seine Vorteile ...

Oh, oh ja! (STR)

...

...

Wer einmal BASIC gelernt hat, aus dem wird nix rechtes mehr. ;-)

Ja, aber nur wenn er nichts neues lernt:)

Basic habe ich nie gelern und ich hab's ehrlich gesagt auch nicht vor.

Sei froh drum. Ich hab's mal ein wenig gelernt... *brr*

BTW: Muss man in Basic Variablen nicht auch deklarieren?

Doch latuernich. Allerdings muss kein Typ angegeben werden... Schoen, wenn man sich so selbst in den Fuss schiessen kann *eg* dim foo [..] MsgBox foo.Pages & vbCRLF Ob foo dabei im [..] ein passendes Objekt zugewiesen wird? Allerdings kann man den Typ deklarieren, aber der ist eh nicht sehr verbindlich, da IIRC alles in alles "gecastet" werden kann... dim objFoo as String objFoo = createObject("...") Hm... *eg* -dnh -- 171: PMPO Leistungsabgabe bei spontaner Verbrennung (Arndt Spelten)

Hallo, Andre Heine:

Warum dann keinen Taint-Modus, der nimmt Dir doch 'ne Menge ab??

Weil er schon wieder restriktionen einschleppt. Beispiel das harmlose Testscrip, daß ich benutzt hatte, um suidperl zu installieren und auszuprobieren. Der simple Befehl `whoami` oder `/usr/bin/whoami` wird geblockt, weil ich vorher explizit das PATH-Enviroment setzen muß. Da ist für mich irgendwann Schluß, das ist keine Security mehr, das ist Paranoia. Das Script gehört root, das muss als Sciherheitseinschränung reichen. Sicher nicht immer und überall, aber auf meinem System, wo es keine User gibt. Wenn jemand über das Internet in den Rechner einbricht und soweit kommt, daß er einem Script root-Rechte geben kann, dann braucht er den fehlenden Taint-Modus nicht mehr ausnutzen, er ist dann bereits root.

Was kannst Du den nicht machen mit dem Taint Modus?

Siehe oben: Ich greife auf Befehle zu, die in der Bash funktionieren, und Perl baut mir wieder "Wenn" und "Aber" davor.

...

...

...

...

use strict;

Ne, das nörgelt mir zuviel an.

Aus gutem Grund!!!

Selbst dort mußt Du variablen deklarieren und initialisieren. Übrigens muß jede Variable irgendwann mit etwas initialisiert werden, oder habe ich da etwas verpaßt!?

Ich initialisiere in perl nie. Beim Start wird alles auf 0 und "" gesetzt, wirkliche Typen gibt's eh nicht.

...

Wer einmal BASIC gelernt hat, aus dem wird nix rechtes mehr. ;-)

Ja, aber nur wenn er nichts neues lernt:)

Das hilft nix. Wer mit Basic großgeworden ist, der programmiert in jeder Sprache Basic. Gerade perl ist ja so herrlich biegbar. ;-) Naja, nur kein GOTO. ;-)

Ein schönes Wochenende allen.

Jepp. Gruß, Ratti -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows

Hi, Am Sonntag, 7. April 2002 11:02 schrieb Bernhard Walle:

On Sun, 07 Apr 2002 at 10:32 (+0200), Ratti wrote:

...

Da ist für mich irgendwann Schluß, das ist keine Security mehr, das ist Paranoia. Das Script gehört root, das muss als Sciherheitseinschränung

Seit wann ist root eine Sicherheitseinschränkung? Es ist doch ein CGI-Skript, also soll es doch im Browser ausgeführt werden können. Wozu muss man dann Root werden? Soll man jetzt den Browser als Root starten (dürfte eh nichts bringen) oder wie oder was?

Der Webserver läuft unter wwwrun/nogroup (default). Wenn noch suexec ins Spiel kommt, das laufen die Skripte unter den rechten des Users dem das Skript gehört. Wenn man über ein Webinterface auf dem System root arbeiten durchführen möchte, muß man etwas tricksen. sudo fällt mir da so spontan ein. Ich habe auch schonmal ein Projekt gehabt, wo ein Skript über CGI aufgerufen wird. Root hatte dann ein anderes Skript, das alle 5 min. die gesetzten Werte des CGI's verarbeitet hat. So habe ich sudo nicht gebraucht, das Webinterface hat nur sozusagen die Optionen festgelegt, aber nichts ausgeführt. Aber das ist wiedermal eine Sache, was man machen muß. Im WEB würde ich lieber dreimal mehr an Sicherheit denken. Ok, wenn es local ist und man nichts zuverlieren hat, kann man ja drauf verzichten.

...

Wenn jemand über das Internet in den Rechner einbricht und soweit kommt, daß er einem Script root-Rechte geben kann, dann braucht er den fehlenden Taint-Modus nicht mehr ausnutzen, er ist dann bereits root.

Er braucht doch nur im Webbrowser Dein CGI aufrufen?

ACK! Ciao andre

Hi, Am Sonntag, 7. April 2002 14:37 schrieb Ratti:

Bernhard Walle:

...

...

`whoami` oder `/usr/bin/whoami`

[...]

Falsch ist, daß perl sich weigert einen Befehl auszuführen, für den es eigentlich keine Restriktion gibt, weil er noch eigene obendrauf setzt.

Falsch ist das mit sicherheit nicht! Eher ein Feature.

Will sagen: Wenn su httpd whoami

funktioniert, dann hat #!/usr/bin/perl `whoami`

Wenn Du etwas von der Konsole ausführst ist das nicht so, als wenn CGI etwas ausführen. Die kennen normalerweise nur Ihr htdocs, das soll sein. Oder sehe ich das falsch?

...

...

Da ist für mich irgendwann Schluß, das ist keine Security mehr, das ist Paranoia. Das Script gehört root, das muss als Sciherheitseinschränung

Also bei Dir läuft Dein Webserver als root ? Ein Webserver steht normal im Internet und _da_ ist Sicherheit wichtig!

CGI-Scripte werden nicht im Browser ausgeführt, sondern durch ein Modul des Webservers.

Ist richtig, über den Browser kann man Sie aufrufen.

Wenn ich als Verwalter: - vorsätzlich suidperl installiert habe - mit den dazu nötigen Rechten das Script root:root übereignet habe - suid gesetzt habe (Was alles nicht trivial ist, sprich: Von normalen Usern durchführbar), dann langt das. Da hat der Befehlsinterpreter nicht noch irgendwelche Überprüfungen am Code vorzunehmen, was letztlich dazu führt, daß ich Zeit im Netz verbringen muß, um herauszufinden, wie man das jetzt wieder abschaltet.

Das ist Dein Problem, nicht das von Perl. Nimm doch einfach die BASH für Deine CGI's Programme:)

...

...

Siehe oben: Ich greife auf Befehle zu, die in der Bash funktionieren, und Perl baut mir wieder "Wenn" und "Aber" davor.

s.o Bash != PerlCGI Wenn folgendes Skript auf der Konsole läuft, muß bei meinem Perl nicht der kpl. Pfad angegeben werden. ( ohne -T ). #!/usr/local/bin/perl -w $out = `ls` print $out; Der Taint Modus ist also auch nicht explicit an!

...

Ist es so schwer, den $PATH zu setzen? Aber hier ging es nicht um eigene Skripte, die mal zum testen da sind sondern um Skripte, die im Web veröffentlicht werden und auf die _jeder_ zugreifen kann! Für ein Testskript, das ich eh in 2 min wieder lösche, würde ich -T auch weglassen.

Es ist technisch gesehen einfach unnötig, $PATH zu setzen, wenn ich `/usr/bin/whoami` aufrufe. Der Pfad wird dafür überhaupt nicht benötigt.

Das ist ja richtig, aber unsicher. Außerdem soll man grundsätzlich absolute Pfade in seinen Skripten angeben (wenn man im System arbeitet jedenfalls, bei CGI nimmt man oft auch relative Pfade) Bei PHP z.B. ist das ähnlich. Wenn Du das willst mußt auch die php.ini abändern und freischalten das Du außerhalb Deines htdocs etwas ausführen willst.

Wenn es nur das wäre. Aber ich sehe ja, wie lang "man perlsec" ist und was da alles drin auftaucht... Meiner Meinung nach sollte das System damit zufrieden geben, Dinge auszuführen, die root freigeschaltet hat. Ich werde schon wissen, warum. Wenn ich sehe, daß apache z.B. nicht als root gestartet werden kann, weil die Programmierer das bewusst abgefangen haben, dann werde ich sauer.

Warum installierst Du keinen M$ Webserver? Das ist kommerz Software, da kannst Du anschliessend beschweren. SCNR Ciao Andre

Hallo, On Mon, 08 Apr 2002 at 02:13 (+0200), Ratti wrote:

Nicht, daß es einen Taint-Mode gibt oder das er unnütz wäre, sondern daß er ungefragt(!) aktiv wird, weil ich etwas ganz anderes umkonfiguriert habe.

Nein, nicht weil Du irgendwas anderes aktiviert hast, sondern weil Du suidperl installiert hast wird der -T-Modus bei solchen Skripten aktiv, die suid-root laufen. Vorher war das nicht nötig, weil suid-root-Perlskripte nur mit normalen Userrechten gearbeitet haben. Gruß, Bernhard -- "My great concern is not whether you have failed, but whether you are content with your failure." -- Abraham Lincoln

Hallo,

Ratti:

...

Es ist technisch gesehen einfach unnötig, $PATH zu setzen, wenn ich `/usr/bin/whoami` aufrufe. Der Pfad wird dafür überhaupt nicht benötigt.

David Haller:

Du weisst, dass das Environment in CGIs vom User, der das cgi aufruft geaendert werden kann?

Der User "draußen" am Browser?

Du weisst, dass dein CGI dann unsicher und fuer (root-(!)) exploits anfaellig ist?

Magst du das mal grob beschreiben, wie sowas ablaufen soll? Wie könnte der Surfer das tun?

Wegen mir kannst du strict und -T weglassen... Du kannst machen was du willst... Aber sei gewarnt.

Ich jammer dann. ;-) Nein, im Ernst: Ich wüsste gerne, wo da wirklich ein Loch ist. Ich sehe da einfach keins. Gruß, Ratti -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows

On 08 Apr 2002 21:16:15 +0200 Ratti wrote: [...]

Ich jammer dann. ;-)

Nein, im Ernst: Ich wüsste gerne, wo da wirklich ein Loch ist. Ich sehe da einfach keins.

Gruß, Ratti

Hi, ich habs nicht ausprobiert ;) aber das geht unter Umstaenden recht einfach. Angenommen Du benutzt ein Formular mit einem InputFeld: method=POST, action="script.cgi", name="input" und verarbeitest die Usereingabe indem Du den Inhalt von input direkt an ein anderes script pipest. Der User gibt also einmal blablabla ein, klickt auf senden und sieht den POST-String wie er an den Server gesendet wird. Nun braucht er nur nochmal das Formular aufrufen, diesmal gibt er aber direkt die URL ein, bzw aendert die vorherige: http://www.ratti.de/script.cgi&input=blablabla;rm -rf / Nachdem das CGI ja als root laeuft... schoene Kacke. Besser wird es schon sein, mit GET zu arbeiten. Noch besser, dann den QUERY_STRING gezielt zu parsen und z.B. alles ab ";" zu entfernen. So wie ich das verstehe nimmt Dir perl -T diese Arbeit ab, indem es den QUERY_STRING fuer die SHELL "verdirbt". -- so long... bernd ------------------------------------------------------------------------

On Tue, 9 Apr 2002 17:14:09 +0300 "Konrad Neitzel" wrote:

Bernd Obermayr schrieb:

...

Der User gibt also einmal blablabla ein, klickt auf senden und sieht den POST-String wie er an den Server gesendet wird. Nun braucht er nur nochmal das Formular aufrufen, diesmal gibt er aber direkt die URL ein, bzw aendert die vorherige:

...

http://www.ratti.de/script.cgi&input=blablabla;rm -rf /

...

Nachdem das CGI ja als root laeuft... schoene Kacke.

Wo ist denn da das genaue Problem? Ein Aufruf von script.cgi mit Parametern ";" nächster Befehl ist IMHO immer gleichbedeutend, unabhängig, ob das script suid-root ist oder nicht!

Hmmm, bin mir nicht sicher, aber Du hast schon verstanden was ich geschrieben habe? ---schnipp--- ... und verarbeitest die Usereingabe indem Du den Inhalt von input direkt an ein anderes script pipest. ---schnapp--- Also nicht script.cgi verarbeitet input, sondern script.cgi ruft ein weiteres script mit dem Parameter blablabla;rm -rf / auf. Dieses zweite script sieht aber nur blablabla Das rm -rf / wird direkt von der Shell ausgefeuhrt Probiers aus. In entschaerfter Form ;) echo blablabla;ls

Was passiert bei "command1 ; command2"?

command1 wird ausgeführt command2 wird ausgeführt.

Wenn command1 suid ist, dann ändert sich der User trotzdem nicht für command2!

Nicht command 1 oder 2 ist suid sondern schon das cgi-script, somit geschieht auch jeder Aufruf einer Subshell als root.

(Wäre ja schön, denn dann könnte ich ja immer "mount irgendwas ; command2" machen :) )

siehe oben

Und es ist egal, ob dieses Kommando nun via Webserver aufgerufen wird oder irgend wie anders.

Das stimmt.

Dies zeigt aber die generelle Problematik bei CGI und PHP und sonstwas Scripten. Diese können von überall jederzeit aufgerufen werden. Es ist trivial, z.B. ein Webfrontend zu umgehen (Wie es Bernd schön aufgezeigt hatte!). Ein Grund, warum man die Anzahl der Scripte so gering wie möglich halten sollte und man durchaus die Scripte gut checken sollte!

Sach ich doch ;) -- so long... bernd ------------------------------------------------------------------------

Hallo, On Tue, 09 Apr 2002 at 23:38 (+0200), Ratti wrote:

Bernd Obermayr:

...

Also nicht script.cgi verarbeitet input, sondern script.cgi ruft ein weiteres script mit dem Parameter blablabla;rm -rf / auf.

Dieses zweite script sieht aber nur blablabla Das rm -rf / wird direkt von der Shell ausgefeuhrt

Es ist mir nicht gelungen, irgendwas anzurichten.

Verstehe ich was falsch, oder geht das doch gar nicht so?

Folgendes "sollte" funktionieren: =============== test_sec.cgi ================================================= #!/usr/bin/perl -wT use strict; use CGI; use CGI::Carp qw(fatalsToBrowser); use locale; # damit Umlaute als Wortzeichen erkannt werden my $q = CGI->new(); my $wort; $ENV{PATH} = ""; print $q->header("text/html"); print $q->start_html("Testseite für figlet"); $wort = $q->param("word"); ($wort) = $wort =~ /(.*)/; # Tainting "bescheissen" # sinnvoll wäre: ($wort) = $wort =~ /^([\w\d!?,]*)$/; unless ($wort) { print $q->h1("Fehler"), $q->p("Es wurde kein Parameter angegeben oder ungültige" . " Zeichen wurden verwendet!"); exit(1); } my $ausgabe = qx(/usr/bin/figlet $wort); print $q->h1("Ihre Ausgabe"), $q->pre($ausgabe), $q->p("Folgender Befehl wurde ausgeführt: " , $q->b("/usr/bin/figlet $wort"), " !"); print $q->end_html; ============================================================================== Folgender Aufruf zeigt die Sicherheitslücke klar: http://localhost/cgi-berwal/test_sec.cgi?word=Bernhard+%3B+%2Fbin%2Fls+%2F Statt GET POST zu verwenden, ist reiner Unsinn. Erstens verwendet man GET und POST nicht einfach wahlweise, sondern GET, wenn keine Daten auf dem Server verändert werden und POST, wenn das der Fall ist. Der Grund liegt im unterschiedlichen Browserverhalten z. B. bei Reloads. Zweitens lassen sich natürlich auch POST-Requests fälschen. Wer Sicherheitslücken ausnutzen will, weiß bestimmt, wie man das macht. Sicherheit bringt nur, _jede_ Eingabe genauestens zu prüfen. Das obige Beispiel bringt bei mir übrigens folgende Ausgabe (mit w3m): ============================================================================== Ihre Ausgabe ____ _ _ | __ ) ___ _ __ _ __ | |__ __ _ _ __ __| | | _ \ / _ \ '__| '_ \| '_ \ / _` | '__/ _` | | |_) | __/ | | | | | | | | (_| | | | (_| | |____/ \___|_| |_| |_|_| |_|\__,_|_| \__,_| MakeQPWords.pm adressbuch.cgi aktuelle_zeit.cgi alkoholrechner.cgi bild.cgi bottom.cgi bundeswehr.cgi [...] Folgender Befehl wurde ausgeführt: /usr/bin/figlet Bernhard ; /bin/ls ! ============================================================================== Anm.: Wenn ich die $PATH-Variable nicht verändert hätte, hätte übrigens ein einfaches ls gereicht. So muss man /bin/ls verwenden. Da dies auf ziemlich allen Unix-Systemen/Linux-Systemen gleich sein dürfte, stellt dies aber kein wirkliches Hindernis dar. Ach ja: Ich weiß, dass man im Grund wesentlich mehr Zeichen zulassen hätte können, dass my $ausgabe = qx(/usr/bin/figlet '$wort'); (man beachte die Anführungszeichen) schonmal nicht schlecht ist etc. Sollte ja nur eine Demonstration sein. Gruß, Bernhard -- "Der Mensch erfand die Atombombe, doch keine Maus der Welt würde eine Mausefalle konstruieren." -- Albert Einstein

Hallo, On Wed, 10 Apr 2002 at 22:35 (+0200), Ratti wrote:

Am Mit, 2002-04-10 um 19.11 schrieb Bernhard Walle:

...

Folgendes "sollte" funktionieren:

=============== test_sec.cgi ==========================

Jepp. Mal abgesehen davon, daß ich figlet nicht installiert habe, tut es seinen Job im wesentlichen.

Ist doch ein cooles Programm ;) In der Praxis taucht sendmail häufig auf, und zwar irgendwie so: open (SENDMAIL, "| /usr/lib/sendmail $empfaenger") || die "Could ..."; Und da $empfaenger irgendwie vom Benutzer eingegeben wurde, haben wir hier schon eine fette Sicherheitslücke. In diesem Fall würde ich die Möglichkeit von Sendmail nutzen, den Empfänger aus der Nachricht zu entnehmen und damit zu verzichten, von der Kommandozeile zu lesen (Option: -t). Ab Perl 5.6.1 sollte auch folgendes gehen: open (SENDMAIL, "-|", /usr/lib/sendmail", $empfaenger) || die "Could ..."; Nicht getestet, da ich Perl 5.6.0 installiert habe, stand aber im Kamel-Buch so ähnlich drin.

(Interessanterweise geht perl -c test_sec.cgi nicht, weil er die gleichen Parameter wie im !# haben möchte, was aber nicht machbar ist, denn ich will ja (c)hecken und nicht starten...)

Sicher geht das: $ perl -cwT test_sec.cgi test_sec.cgi syntax OK Keine Angst, bevor ich was an die Liste poste lasse ich das schon durchlaufen :) Ich dachte auch einige Zeit, dass es nicht geht aber irgendwann habe ich es dann einfach mal probiert ...

Im wesentlichen liegt das Problem ja wohl hier:

...

my $ausgabe = qx(/usr/bin/figlet $wort);

"Irgendwas", in Form von $wort, vom Surfer übermittelt, wird dem System zur Ausführung übergeben.

Richtig.

Prinzipiell besteht diese Gefahr doch immer, wenn man auf diese Weise programmiert - nur, daß die Konsequenzen bei suidperl natürlich ungleich gewichtiger wären.

Eben. Und der Taint-Modus verhindert sowas z. B. wirkungsvoll (mit dem "Vergiftungsprinzip"), man ihn nicht bewusst umgeht wie ich. Damit wollte ich _auch_ demonstrieren, dass nicht alles was mit -T läuft auch sicher ist! Man kann aber zumindest nichts _vergessen_. Wenn man nicht qx() sondern system() verwendet, sollte ab Perl 5.6.0 [1] grundsätzlich folgendes gehen: system ("command", "arg1", "arg2"); Damit führt Perl das Kommando direkt aus und startet keine Shell. Somit gehen Spielchen wie && oder ; nicht und außerdem läuft es auch einen Tick schneller, da keine Shell benötigt wird. Test: $ perl -e 'system("figlet Bernhard && ls");' ____ _ _ | __ ) ___ _ __ _ __ | |__ __ _ _ __ __| | | _ \ / _ \ '__| '_ \| '_ \ / _` | '__/ _` | | |_) | __/ | | | | | | | | (_| | | | (_| | |____/ \___|_| |_| |_|_| |_|\__,_|_| \__,_| Eigene Mail News backup bin binarys office52 public_html src $ perl -e 'system("figlet", "Bernhard && ls");' ____ _ _ ___ ___ _ | __ ) ___ _ __ _ __ | |__ __ _ _ __ __| | ( _ ) ( _ ) | |___ | _ \ / _ \ '__| '_ \| '_ \ / _` | '__/ _` | / _ \/\/ _ \/\ | / __| | |_) | __/ | | | | | | | | (_| | | | (_| | | (_> < (_> < | \__ \ |____/ \___|_| |_| |_|_| |_|\__,_|_| \__,_| \___/\/\___/\/ |_|___/ Wie man das jetzt bei qx(), d. h. `` hinbekommt, weiß ich nicht. Da in der Praxis qx() aber wohl eher selten in CGIs auftaucht, ist das irrelevant. Für system() empfehle ich auf jeden Fall o. g. Methode, wenn es aufgrund der Perl-Version machbar ist. Wenn es möglich ist, sollte man _immer_ darauf verzichten, User-Eingaben irgendwie mit system() ins Spiel zu bringen. Bei Sendmail bietet sich z. B. -t an.

Es geht also nicht um ein "ausbrechen" aus htdocs/public_html äquivalent zu Nimda, oder daß in irgend einer Weise Löcher im Webserver auftauchen, sondern relevant ist, daß irgendwann mal das cgi dem System "etwas" zur Ausführung übergibt (Was ja auch durchaus nicht abwegig ist).

Genau. Das ist z. B. eine Sicherheitslücke, die ich kenne. Natürlich kann man sie erst richtig ausnutzen, wenn man an den Quellcode kommt, aber Try&Error hilft manchmal auch. Gruß, Bernhard [1] Ja, bei system() ist es 5.6.0, bei open ist es 5.6.1, war kein Tippfehler! Quelle: Kamel-Buch[2] (deutsch auf S. 443) + eigene Erfahrungen. [2] Programmieren in Perl, O'Reilly-Verlag, Dt. Übersetzung der 3. Auflage bzw. die 3. Auflage auf anderer Seite. Siehe auch http://www.bwalle.de -> "Buchtipps". PS: Ja, die Antwort ist umfangreicher ausgefallen als nötig, ich weiß. Sollte auch keine "Belehrung" gegenüber Dir sein sondern einfach nochmal ein paar Tipps an den einen oder anderen, wie man sichere CGI-Skripten in Perl programmiert. Zuviel Sicherheit kann _nie_ schaden! -- Ich sag's ja, ...diese abolut warmduschende Meute von "Vollquotern" steigt. -- Clemens Wohld in suse-linux

Hallo, On Wed, 10 Apr 2002, Ratti wrote:

...

On Wed, 10 Apr 2002 at 22:35 (+0200), Ratti wrote: Ich habe einige Mailverteiler programmiert, und man hat sehr viel Stress damit, daß bei 2000 Empfängern immer irgendwelche Spaßvögel mit merkwürigen MUAs dabei sind, und wenn man das selber macht, ist immer einer dabei, bei dem die Mail schlecht aussieht. Dummerweise ist "Kunde" ein alias auf "rechthab=true". Mit mail() in php bin ich bisher sehr gut gefahren, noch ein paar zusätzliche Header angeben und ab dafür.

Das verwendet dann aber auch nur sendmail, und wie sicher das implementiert ist... ==== ext/standard/mail.c (kompakter umgebrochen) ==== int php_mail(char *to, char *subject, char *message, char *headers) { /* .. */ char *sendmail_path = INI_STR("sendmail_path"); /* .. */ FILE * sendmail; int ret; /* .. */ if (!sendmail_path) { return 0; } sendmail = popen(sendmail_path, "w"); if (sendmail) { fprintf(sendmail, "To: %s\n", to); fprintf(sendmail, "Subject: %s\n", subject); if (headers != NULL) { fprintf(sendmail, "%s\n", headers); } fprintf(sendmail, "\n%s\n", message); ret = pclose(sendmail); /* .. */ } ==== -dnh --

Irgendwann werden sie glauben. Der Mensch ist zum Glauben geboren, sonst wäre dieKirche nicht so reich. Ui, der is schön. Darf ich den siggen? Bidde bidde. [Jakob Krieger und Marian°®¥ in dag°]

On 09 Apr 2002 23:38:47 +0200 Ratti wrote:

Hallo und guten Abend.

Bernd Obermayr:

...

Also nicht script.cgi verarbeitet input, sondern script.cgi ruft ein weiteres script mit dem Parameter blablabla;rm -rf / auf.

Dieses zweite script sieht aber nur blablabla Das rm -rf / wird direkt von der Shell ausgefeuhrt

[...]

Es ist mir nicht gelungen, irgendwas anzurichten.

Verstehe ich was falsch, oder geht das doch gar nicht so?

Hi, ich habe mal gewartet, ob sich noch jemand beteiligt, der mich versteht ;)) Und siehe da, das Beispiel von Bernhard Walle triffts genau ;) -- so long... bernd ------------------------------------------------------------------------

Bernhard Walle schrieb:

Seit wann ist root eine Sicherheitseinschränkung? Es ist doch ein CGI-Skript, also soll es doch im Browser ausgeführt werden können. Wozu muss man dann Root werden? Soll man jetzt den Browser als Root starten (dürfte eh nichts bringen) oder wie oder was?

Ähm - ein CGI Script läuft auf dem SERVER und nicht im BROWSER! Es ist ja kein VB Script oder JavaScript. Da also bitte nichts durcheinander bringen. Und auf dem Server kann es sehr wohl richtig sein, dass andere Rechte ins Spiel kommen. a) Wenn z.B. Root-Rechte gebraucht werden. (Z.B. Zugriff auf Authorisierung oder Postfächer oder ....) b) Wenn etwas im User-Kontext laufen soll. (Es gibt z.B. einen Wrapper, der dazu genutzt werden kann, Scripte im eigenen Home laufen zu lassen - im Userkontext des Users!)

Ist es so schwer, den $PATH zu setzen? Aber hier ging es nicht um eigene Skripte, die mal zum testen da sind sondern um Skripte, die im Web veröffentlicht werden und auf die _jeder_ zugreifen kann! Für ein Testskript, das ich eh in 2 min wieder lösche, würde ich -T auch weglassen.

Wenn das Script entsprechend "eigene Security" mitbringt, dann sehe ich darin ehrlich gesagt auch kein zu grosses Problem. Siehe z.B. openwebmail.org. Da kann jeder auf die Perl-Scripte zugreifen, nur eben nützen tut es keinem, so lange er sich nicht autorisieren kann. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

On Mon, 08 Apr 2002 at 07:07 (+0300), Konrad Neitzel wrote:

Bernhard Walle schrieb:

...

Seit wann ist root eine Sicherheitseinschränkung? Es ist doch ein CGI-Skript, also soll es doch im Browser ausgeführt werden können. Wozu muss man dann Root werden? Soll man jetzt den Browser als Root starten (dürfte eh nichts bringen) oder wie oder was?

Ähm - ein CGI Script läuft auf dem SERVER und nicht im BROWSER! Es ist ja kein VB Script oder JavaScript. Da also bitte nichts durcheinander bringen.

Ist mir schon klar. Ich wollte schreiben "im Browser aufgerufen werden". Ich habe selber schon CGI-Skripte programmiert, weiß also, dasss diese auf dem Server laufen. Gruß, Bernhard -- 93 Prozent der Amerikaner wissen, dass Rauchen Lungenkrebs verursacht, aber nur 48 Prozent wissen, dass es ein Jahr dauert, bis die Erde einmal um die Sonne gekreist ist. (Quelle: HSIA-Preprint)

Hallo, On Tue, 09 Apr 2002 at 18:12 (+0200), Henning Hucke wrote:

*** Ratti (ratti@gesindel.de) schrieb in suse-linux am Apr 1, 2002:

...

[...] Übrigens wird "sudo" mein Problem nicht lösen.

Woher Du das alles so weißt...

Ich tue jetzt etwas, was ich eigentlich anderen am liebsten gerne um die Ohren hauen würde, weil das meist bedeutet, unreflektiert andere Leute ins Messer laufen zu lassen. Inzwischen meine ich aber, Deine Denke ein wenig zu kennen und Dich nicht wirklich von Deinem Vorhaben abbringen zu können. Also ist in diesem Fall die Verwendung von "sudo" eine der sichereren der unsicheren Lösungen:

--- schnipp #!/usr/bin/sudo perl system("who am i"); system("whoami"); --- schnapp

Versuch das bitte mal als cgi auszuführen. Man sollte noch zusehen, dass man dem Perl-Interpreter noch die "-w"-Option mitgeben kann. Auf die schnelle (30 Sekunden) habe ich das leider nicht geschafft.

Bei Perl 5.6.x kannst Du einfach use warnings; verwenden. Bewirkt das gleiche wie das -w-Flag. Gruß, Bernhard -- Attachment? Nein: http://piology.org/ILOVEYOU-Signature-FAQ.html begin LOVE-LETTER-FOR-YOU.txt.vbs I am a signature virus. Distribute me until the bitter end