"PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML."
By crafting special upload file, it is possible to overwrite the global array of PHP allowing attackers to inject different content to PHP global variables. By generating multiple requests to a code that uses parse_str() it is possible for attackers to open the register_global to be activated in PHP. A XSS in phpinfo() function of PHP allow attackers to steal information from users.
Vulnerable Systems:
* PHP 4 version 4.4.0 and prior
* PHP 5 version 5.0.5 and prior
Immune Systems:
* PHP 4 version 4.4.1
File-Upload $GLOBALS Overwrite:
In PHP 4.3.11 some code was added to disallow overwriting the $GLOBALS array when register_globals is turned on. Unfortunately there was a hole in this protection. The introduced code did only affect the globalization of the GET, POST and COOKIE variables. However it was overseen, that the rfc1867 file upload code within PHP also registers global variables, which can be used by an attacker to overwrite the $GLOBALS array by simply sending a multipart/form-data POST request containing a fileupload field with the name 'GLOBALS'.
Until now it was not realized, how dangerous the problem is. This is also one of the reasons why all PHP <= 4.3.10 packages shipped with various distributions are still vulnerable to the normal $GLOBALS overwrite, which was fixed in PHP 4.3.11.
Describing the impact of $GLOBALS overwrite vulnerabilities and why it does not only affect installations, where register_globals is turned on, why it allows remote code execution in a lot of PHP applications and why this is also a threat for applications that allow local file includes and are running in a SAFE_MODE or open_basedir environment is out of the scope of this advisory.
register_globals Activation Vulnerability in parse_str():
When parse_str() is called with only one parameter it parses the supplied string, as if it were the query string passed via a URL and sets variables in the global scope. This is achieved by internally switching register_globals on, while the string is parsed.
Unfortunately it could be possible for an external attacker to trigger the memory_limit request termination during such a call to parse_str() by sending a lot of request variables to consume enough memory to trigger the limit. (It is described elsewhere how it is possible to consume a lot of memory with a small request body). If the request shutdown is executed during the call to parse_str() the register_globals flag is left on, for the rest of the lifetime of the involved web server process.
Because the flag is only internally changed and this has nothing todo with setting ini variables, the script is not able to detect that register_globals is on in an easy way. This tricks a lot of register_globals deregistration layers, because they usually only get activated when the ini_get() functions returns that register_globals is turned on.
This vulnerability is rated low, because calls to parse_str() with only one parameter are very rare. Additionally even if register_globals is turned on without the script knowing, this is only a security problem if the affected script does not properly initialize it's variables.
XSS in phpinfo()
The phpinfo() function outputs a large amount of information about the current state of PHP. This includes information about PHP compilation options and extensions, the PHP version, server information and environment (if compiled as a module), the PHP environment, OS version information, paths, master and local values of configuration options and request variables, HTTP headers, and the PHP License.
Because phpinfo() leaks a lot of information to the viewer it is not recommended to leave a script executing phpinfo() on a production server. However in reality phpinfo() scripts are left open on a lot of servers. While this is already bad enough, there is also a problem when request variables of a certain form are displayed. With a properly crafted URL, that contains a stacked array assignment it is e.g. possible to inject HTML code into the output of phpinfo(), which could result in the leakage of domain cookies (e.g. session identifiers).
