register_globals auf On gestellt

Oh je, mein Lieblingsthema ;-) Ich versuche, mich zurückzuhalten ...

Mit register_globals=on ist die Gefahr größer, dass ein Fehler im PHP-Skript ausgenutzt werden kann. Mal ein Beispiel:

if (passwort_gueltig()) {
    $user_reinlassen = true;
}
if ($user_reinlassen) {
    // etwas machen, was nur registrierte User machen dürfen
}

Mit register_globals=on könnte man so ein Skript einfach über eine URL aufrufen, die $user_reinlassen auf true setzt: http://deinesite.de/login.php?user_reinlassen=true ... und schon wäre der User "drin", ohne ein gültiges Passwort eingeben zu müssen.

Das ist im Wesentlichen die Argumentation, auf die die Gegner von register_globals=on bauen. Meine Meinung dazu ist: Wer solche Skripte schreibt oder einsetzt, der hat noch ganz andere Probleme ...

Es ist richtig, dass bei aktiviertem register_globals mehr Sorgfalt auf die Programmierung der Skripte verwendet werden muss. Im o.g. Beispiel reicht es aber schon, einfach vor dem Test auf ein gültiges Passwort die Variable $user_reinlassen einmal explizit auf false zu setzen und schon kann sie nicht mehr per URL "überschrieben" werden.

Geeklog hat auch schon seine Sicherheitsprobleme gehabt, aber keines davon war auf die register_globals- Einstellung zurückzuführen.

Ja, idealerweise sollte Geeklog mit register_globals=off funktionieren. Wir haben uns das überlegt und entschieden, dass es zuviel Arbeit wäre, die zudem die Gefahr neuer Fehler heraufbeschwören würde (der gegenwärtige Code ist schließlich getestet und bewährt). Geeklog 2 wird dann auch mit register_globals=off laufen.

Dass ein Hoster es sich leisten kann, register_globals auf off zu stellen, wundert mich. Es gibt noch eine ganze Menge PHP- Software da draußen, die dann auch nicht laufen wird und der Hoster läuft Gefahr, es sich mit seinen Kunden zu verscherzen.

Durch register_globals kann bestimmt niemand Root des Webservers(!) werden. Es gab aber mal einen Fehler im Upload-Code von PHP - setzte der Hoster etwa eine alte PHP-Version (vor 4.1.2) ein? Dann wäre er aber selbst schuld, denn der Fehler ist ja nun wirklich schon lange bekannt (und behoben) ...

bye, Dirk

HI Dirk!

Danke für Deine ausführliche Antwort, ich werde das mal an den
System-Admin weiterleiten. Das Problem ist nämlich, dass mein
geeklog privat bei einer Firma gehostet wird, wo noch das ganze
Firmen-Netz dranhängt. Und auf einmal ist das nun eine potentielle
Sicherheitslücke und sie wollen nun intern einen Rechner bereitstellen,
wo z.B. das geeklog dann laufen kann ...

Wann es soweit sein wird, weiß ich nicht und deshalb bin ich auf der
Suche nach einem kommerziellen Prodider, der PHP mit
register_gobals On hostet, vielleicht hast Du ja einen Tipp?

bye, ein Unwissender

Eigentlich ist bei allen kommerziellen Hostern register_globals
noch auf \"on\", da sie, wie gesagt, sonst Ärger mit ihren Kunden
bekommen würden, die bestimmte Skripte (nicht nur Geeklog
...) nicht laufen lassen könnten.

Bei Puretec und Strato ist register_globals auf jeden Fall \"on\"
(womit ich nicht gesagt haben will, dass bzw. ob ich diese
Anbieter empfehle ;-)

geeklog.info ist bei domainfactory.de gehostet.

bye, Dirk

Wie Dirk schon sagte, kann die Einstellung register_globals=on alleine einem User keine Root-Rechte verschaffen. Es kann aber schnell passieren, dass wenn register_globals auf on ist UND safemode aus bzw die Moeglichkeit Shell-Befehle auszufuehren gegeben ist, entsprechende Bugs in Software auszunutzen.
So gab es beispielsweise eine Luecke in phpBB2 (die Software hab ich eh gefressen.. so viele Luecken wie da hab ich noch nie woanders gesehn), bei der man aufgrund von register_globals=on (und fopen-wrappers) als Angreifer eine externe Datei includen und so jeglichen PHP-Code ausfuehren konnte auf dem Server, z.B. diese Shell-Befehle. In Zusammenhang mit einem der ptrace etc Luecken im Kernel, hat man dann ganz schnell nen Root-Zugang zum Server.
Wie man sieht, war hier register_globals notwendig, aber bei weitem nich die einzige Ursache.

Gruss
Michael