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

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, On Mon, 01 Apr 2002 at 20:52 (+0200), Ratti wrote:

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

Wahrscheinlich verwendest Du die Programmiersprache Perl. Für sowas gibt es /usr/bin/suidperl, das allerdings bei SuSE aus Sicherheitsgründen standardmäßig nicht mit dem SUID-Bit ausgestattet ist. Kann man aber leicht nachholen. Dann muss noch das Skript mit passenden Rechten versehen werden (also SUID-Bit gesetzt, User root) und dann sollte es gehen! Die Shebang-Line muss nicht in /usr/bin/suidperl geändert werden. Anscheinend ist Perl selbst so schlau und ruft suidperl bei Bedarf auf. Nein, /usr/bin/perl hat bei mir _keine_ SUID-Rechte: $ ls -l /usr/bin/perl -rwxr-xr-x 2 root root 775822 Mai 11 2001 /usr/bin/perl $ ls -l /usr/bin/suidperl -rwsr-xr-x 2 root root 777442 Mai 11 2001 /usr/bin/suidperl Wenn ich /usr/bin/suidperl auf die gleichen Rechte wir /usr/bin/perl setze, was bei SuSE standardmäßig der Fall ist, verabschiedet sich das Skript nur mit "Can't do setuid". ========================= test.pl ========================= #!/usr/bin/perl open (FILE, "/etc/shadow") or die "Could not ...: $!"; while (<FILE>) { if ($. == 5) { print; } } close FILE or die "Could not ...: $!"; ============================================================ $ ls -l test.pl -rwsrwsr-x 1 root root 165 Apr 2 09:22 test.pl $ ./test.pl news:*:8902:0:10000:::: HTH. Keine Garantien bzgl. Sicherheit von mir! Gruß, Bernhard -- Freedom is just another word for nothing left to lose, Nothing don't mean nothing honey if it ain't free, now now. And feeling good was easy, Lord, when Bobby sang the blues, You know feeling good was good enough for me, Good enough for me and my Bobby McGee. -- Janis Joplin

* Ratti schrieb am 02.Apr.2002:

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?

Per sudo könnte ich m.E. den Zugriff auf sagenwirmal ipchains freigeben oder dergleichen.

Aber was ist mit sowas (in perl):

*an der Stirn klopf* Klar, Du verwendest perl, ist bei cgi ja meist so. Hätte ich auch drauf kommen können. Ich bin von einem shellskript ausgegangen. Was ja AFAIK mit cgi auch funktionieren würde.

open LESEN , "< /var/spool/mail/root";

Da würde mir sudo nicht helfen.

Nein, weil Du Dich in perl befindest. Aber dazu hat Konrad ja schon was geschrieben. Bernd

Hallo, Ratti:

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

Ich hab es mit eurer Hilfe geschafft. Das war wirklich ein weiter Weg. Ich dokumentiere ihn hier noch mal zusammenfassend. Suse erlaubt kein s-Bit bei Scripten. Von dieser Einstellung sind auch cgis in perl betroffen. Um das zu umgehen, gibt es suidperl. Erster Fallstrick: Ich hatte irgendwann mal perl selbst kompiliert. Beim konfigurieren wird man gefragt, ob das System "sicher" sei und ob man gerne die Möglichkeit hätte, Scripte als root auszuführen. Defaultantwort ist NEIN. Das ist schonmal schlecht. Hier "ja" angeben, sonst wird suidperl gar nicht erst erzeugt. Wenn man es dann endlich hat, hat es aber die falschen Rechte. Dazu befindet sich ein Artikel in der SDB. Kurzfassung: In die Datei /etc/permissions.local eintragen: /usr/bin/suidperl root.root 4755 und SuSEconfig starten. Dann werden die Rechte korrekt gesetzt und bleiben es auch. Zweiter Fallstrick: Das perl-Script muß gegenüber einem "normalen" Script verändert werden. Es wurde hier angegeben, daß der suidperl als Interpreter im !# angegeben werden müsste. Das ist m.E. nicht nötig. Allerdings muß der Pfad "beschnitten" werden. So lieferte print `whoami`; ebenso eine Fehlermeldung wie print `/usr/bin/whoami`; Erst durch vorheriges Einfügen von $ENV{'PATH'} = '/bin:/usr/bin:/usr/sbin:/usr/bsd:/usr/local/bin'; ließ sich das Script dann endlich zum funktionieren bewegen. Permissions und Eigentümer: ls -la probe.pl -rws--s--x 1 root root 187 Apr 2 21:55 probe.pl Inhalt der Datei: #!/usr/bin/perl print ("Content-type: text/html\n\n"); print "<HTML>"; $ENV{'PATH'} = '/bin:/usr/bin:/usr/sbin:/usr/bsd:/usr/local/bin'; $x= `/usr/bin/whoami`; print "I am $x<\/HTML>"; Und schliesslich der HTML-Output: I am root Yes, you are. :-) Danke nochmal, Gruß, Ratti

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)

Bernhard Walle:

BTW: Muss man in Basic Variablen nicht auch deklarieren?

Naja, solche Kampfmaschinen wie VisualBasic heutzutage haben nicht mehr viel mit dem CBM-BAsic zu tun, mit dem ich mal angefangen habe, aber so im Kurzüberflug: Nein. In VB gibt es den Variablentyp "Variant", der ist den perl-Skalaren recht ähnlich. Je nach Kontext ist er Zahl oder Zeichenkette. Es gibt auch explizit Integer, Float, String, ... Aber wenn du einfach gar nicht deklarierst, initialisiert, ... ist der Typ Variant und der Inhalt je nach kontext 0 oder "". Also: Ne, du brauchst gar nix tun. Ich bin auch in den letzten 18 Jahren nur sehr selten auf Sprachen getroffen, wo man das noch muß. Pascal und C. Beide wurden von mir getestet und verworfen. ;-) 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

Moin, Ratti:

...

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

Andre Heine:

Falsch ist das mit sicherheit nicht! Eher ein Feature.

Whatever...

...

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.

Wenn ich es in `` setze, dann sollte es aber eigentlich genau das sein.

Die kennen normalerweise nur Ihr htdocs, das soll sein. Oder sehe ich das falsch?

Ich glaube - ja, siehst du falsch. ;-) Du kannst normalerweise völlig problemlos in einem CGI `/usr/bin/whoami` schreiben, es funktioniert auch. Ich brauchte aber root-Zugriff für ein cgi und hab suidperl aktiviert. Jetzt geht der Befehl nicht _mehr_.

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

Nein, mein cgi läuft als root. Apache lässt sich als root gar nicht starten... Du hast das Thema nicht von Anfang an mitverfolgt? Ich wollte mir OpenWebMail installieren, das läuft als cgi und bietet per Web Zugriff auf lokale Mails. Dafür braucht es natürlich Zugriff auf /etc/passwd , /var/spool/mail ,... Das heisst: Der Webserver (apache als nobody:nogroup) ruft webmail.pl (suid root:root) auf. Suid funktioniert aber nicht bei Scripten. Also habe ich suidperl installiert, das erlaubt das "hochsetzen" der Rechte. Jetzt gehen aber andere Sachen nicht mehr, die vorher noch gingen, weil perl mir Restriktionen aufzwingt, die ohne suidperl nicht vorhanden waren. Mich stört einfach, daß man perl geradezu kaputtkonfigurieren muß, weil es ungefragt Features aktiviert, die auf vielen Systemen keinen Sinn machen.

...

...

...

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

Falsch. Dafür sind die `-Zeichen ja da. PerlCGI != Bash aber `PerlCGI` = Bash Naja, im Groben.

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!

Ich denke mal, du benutzt auch perl und nicht suidperl und hast nicht mitbekommen, worum es geht. Obiges funktioniert bei mir auch, und auch der Taint-Mode ist aus. Dann setze ich die Rechte von 0755 auf 6755, und es funktioniert nicht mehr, und auch der Taint-Mode ist jetzt aktiv. Das cgi ist erst wieder zum Laufen zu bekommen durch Einfügen der Zeile $ENV{'PATH'} = '/bin:/usr/bin:/usr/sbin:/usr/local/bin'; um explizit Code in /bin ausführen zu dürfen (Dort liegt "ls"). Und das nervt mich. 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.

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)

Ich habe einen absoluten Pfad eingegeben. Das nützt nichts.

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.

...was ich natürlich schon lange getan habe. safe_mode... ;-)

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

Nutze ich ebenfalls. Hat alles Vor- und Nachteile. Gruß, Ratti -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows

On Mon, Apr 08, 2002 at 07:07:28AM +0300, Konrad Neitzel wrote:

Ä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 ^^^^^^^^^^

man "iPlanet Server", also Netscapes Webserver. Kennt und benutzt JavaScript Peter

Hallo, On Mon, 08 Apr 2002, Ratti wrote:

...

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?

Jep.

...

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?

In dem er das GET/POST manipuliert. Ist der gleiche Mechanismus wie bei Nimda, nur wird da eben nicht ein Buffer-Overflow ausgenuetzt, sondern es wird eben das Environment, das das cgi zu sehen bekommt manipuliert. Ich zitiere: ==== man 1 perlsec ==== You may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, [..], and all file input are marked as "tainted". Tainted data may not be used directly or indi­ rectly in any command that invokes a sub-shell, nor in any command that modifies files, directories, or processes. ==== Der Grund ist eben, dass das Environment (und die anderen angesprochenen Quellen fuer Daten) eben (boshaft) manipuliert werden koennen. Aber wenn man bei dir irgendwie Dateien raufladen kann, dann reicht ein script/binary in .../incoming und eine "kleine, unauffaellige Aenderung des PATH auf PATH=".../incoming:$PATH" und du hast Aerger am Hals, und wenn das cgi dann noch root-Rechte hat *brr*. Nein, ich kann dir kein besseres Beispiel geben, da ich mit sowas nicht beschaeftige, glaub's den Programmieren von Perl einfach, dass der Taint Modus (und -w und strict!) sinnvoll und bei cgis eigentlich unverzichtbar sind. Ach ja: ==== man 1 perl ==== BUGS The -w switch is not mandatory. ====

...

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

Ich jammer dann. ;-)

Und ich lache dann haemisch. ;-)

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

Tja. Es ist aber vorhanden (s.o.). Wie war das noch gleich? "Better safe, than sorry"... ;) -dnh -- Human beings were created by water to transport it uphill. -- BSD fortune file

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! 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! (Wäre ja schön, denn dann könnte ich ja immer "mount irgendwas ; command2" machen :) ) Und es ist egal, ob dieses Kommando nun via Webserver aufgerufen wird oder irgend wie anders. 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! Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

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

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

[...] Ich habe aus dem Script, das configure aufruft, "--enable-suexec" rausgeschmissen, neu installiert und aus /usr/local/apache/bin das noch vorhandene suexec gelöscht. Dann den apache neugestartet.

Nunja. *Grundsätzlich* hast Du Dich _gerade damit_ der ansich einzigen sicher funktionierenden Möglichkeit beraubt, das zu erreichen, was Du willst.

[...] Ü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. ACHTUNG Kinder!!! Sowas bitte nicht zuhause benutzen. Ihr werdet damit fast zwangsläufig vor die Wand laufen und/oder euch für eine eventuelle zukünftige Admin-Tätig- keit etwas falsches angewöhnen! MG Henning Hucke -- "nobody is perfect." -- Nobody ;)

-----Ursprüngliche Nachricht----- Von: Bernhard Walle [mailto:Bernhard.Walle@gmx.de]

Hallo? Bernhardt, kannst Du bitte mal Deinen Rechner auf Viren oder ähnliche Spielereien überprüfen? Mit Anhängen wie LOVE-LETTER-FOR-YOU.txt.vbs macht man sich in Mailinglisten nicht sehr beliebt. Glaub ich jedenfalls.

Attachment? Nein: http://piology.org/ILOVEYOU-Signature-FAQ.html *argg*

Mit freundlichen Grüßen, Carsten Breitbarth --- | web: http://www.realxonic.de | email: mailto:ich@realxonic.de | icq: - | | "Der Pinguin ist ein gutes Logo für Linux, | denn was nicht fliegt, stürzt auch nicht ab." | Francis Kuhlen (IBM-Vice President Sales) ---

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

Erstmal eines vorweg: Wenn Listenuser, die ich für Kompetent halte, erklären, was ich da treibe, sei gefährlich, dann nehme ich das durchaus ernst. Bitte versteht es also nicht so, als wäre mir das alles egal oder ich würde euch nicht glauben. Ich bin sehr dankbar für die Erklärungen. Trotzdem möchte ich mich mit allgemein gehaltenen Gefährlichkeitserklärungen nicht zufrieden geben. Die nützen nicht, wenn ich nicht verstehe, wo die Lücke denn nun ist. Ich möchte euch daher bitten, sie mir zu erklären. Bernd: Ich habe deine Mail mal als Anregung genommen. Auf meinem "Intranet-Webserver" habe ich im $HOME/public_html von "ratti" immer die Dateien "probe.cgi" und "probe.pl" liegen, die nur ein "Hallo" ausgeben. Ist halt praktisch, ein funktionierendes cgi griffbereit zu haben, wenn man mal wieder geschraubt hat. ;-) Um gezielt "sabotieren" zu können, benutze ich keinen Browser, der meine Anforderung wohlmöglich selbst schon verändert, sondern telnet 192.168.0.1 http Ich teste natürlich auch nicht mit "rm -rf", sondern mit "ls" und "touch". Mit GET und POST habe ich nach folgendem Schema mehrere Dinge probiert: GET 192.168.0.1/~ratti/probe.pl ; touch ohgottogott.txt GET, POST, und auch "|" statt ";". Es ist mir nicht gelungen, irgendwas anzurichten. Verstehe ich was falsch, oder geht das doch gar nicht so? Gruß, Ratti -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows

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 Bernhard, 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. (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...) 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. Prinzipiell besteht diese Gefahr doch immer, wenn man auf diese Weise programmiert - nur, daß die Konsequenzen bei suidperl natürlich ungleich gewichtiger wären. 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). OK, ich sehe das Problem jetzt sehr viel klarer. Vielen Dank für die sehr ausführliche Info. Würde ich (theoretisch) dieses Beispielprogramm unbedingt brauchen, und zwar als root, müsste ich also sehr genau checken, was da übergeben wird, und ggf. für einen bombensicheren Übergabestring sorgen. Kennt jemand noch andere Fallen? Gruß, Ratti -- http://www.gesindel.de | Fontlinge | Die Schriftenverwaltung für Windows

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