mailing list archives
Re: PHPCentral Login Script Remote Command Execution Vulnerability
From: "Steven M. Christey" <coley () mitre org>
Date: Tue, 14 Aug 2007 21:09:42 -0400 (EDT)
Magnus Holmgren said:
[the superglobals] shadow everything - you cannot define your own
$_SERVER array, nor can it be overridden with HTTP GET or POST
values. If that were possible, using the superglobals would be
useless; all scripts would be vulnerable unless register_globals is
This EXACT problem occurred in older versions of PHP, at least 4.x if
I recall correctly, although I can't dig up which versions were
affected. Now, you could argue that this is the PHP interpreter's
fault, so the applications shouldn't be held accountable, but we see a
lot of reports like this one - and I bet they work in many
environments. Then there's the unset() vulnerability  and other
Ignoring register_globals, there's still dynamic variable evaluation
, extract(), and other variable-overwriting constructs, from which
I suspect even the superglobals aren't always protected, although
these constructs don't seem to be used very heavily.
Now, register_globals has defaulted to off ever since PHP 4.2.0.
This is a reasonable argument. However, many hosting sites and
applications still enable or require it. The mass compromises of web
servers for botnets, as described by Gadi Evron , were probably
made possible due to this setting (and allow_url_fopen).
And it would of course be nice if people posting to Bugtraq actually
tested their PoCs first.
This would be nice, but as you see, sometimes a "fake" isn't always so
immediately identified, thanks to the colorful, complicated history of
the PHP interpreter itself   .
 Zend_Hash_Del_Key_Or_Index Vulnerability
 Dynamic Evaluation Vulnerabilities in PHP applications
 "Web server botnets and hosting farms as attack platforms"
Gadi Evron, Kfir Damari & Noam Rathaus, Virus Bulletin, February 2007
 $GLOBALS Overwrite and it's Consequences
 PHP import_request_variables() arbitrary variable overwrite
Stefano Di Paola