note 41656 added to language.variables.predefined

-Security issue- In response to lopez at yellowspace, You provided a method for executing potentially unsafe code: > function safeEval($evalcode) { > unset($GLOBALS); > unset($_ENV); > // unset any other superglobal... > return eval($evalcode); > } Your method, though clever, won't work. The problem is the way that PHP handles function scope. If $evalcode contains a function declaration, and runs that function, the "unset"s will be effectively useless inside the body of that function. Try running the above code with $evalcode set as follows: <?php $evalcode='f(); function f() { $GLOBALS["_SERVER"] = "compromised"; }'; ?> Then print $_SERVER and see what you get. Another problem is that the "global" directive will always grant access to global variables. Try this one: <?php $evalcode='global $a; $a = "compromised";'; ?> $a will of course be changed at the global level. I don't know if it's supposed to work this way, but on my system (PHP 4.3.4) you can do the same to any superglobal by importing it using "global". As far as I can tell, there is NO way to execute potentially unsafe code without a lot of risk. With the sloppy way that PHP deals with function scope etc., there isn't much hope that it ever will be. What we'd need is (at least): - a way to disable the "global" directive (restrictive eval). - a way to shut off any write-access to superglobals within untrusted functions. The first wouldn't be too hard to implement. The second, on the other hand, is practically impossible IMHO. ---- Manual Page -- http://www.php.net/manual/en/language.variables.predefined.php Edit -- http://master.php.net/manage/user-notes.php?action=edit+41656 Delete -- http://master.php.net/manage/user-notes.php?action=delete+41656&report=yes Reject -- http://master.php.net/manage/user-notes.php?action=reject+41656&report=yes Search -- http://master.php.net/manage/user-notes.php