PHP register_globals Activation Vulnerability in parse_str()

2005-10-31 / 2005-11-01
Credit: Stefan Esser
Risk: Low
Local: No
Remote: Yes
CWE: CWE-Other


CVSS Base Score: 5/10
Impact Subscore: 2.9/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: None
Integrity impact: Partial
Availability impact: None

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hardened-PHP Project www.hardened-php.net -= Security Advisory =- Advisory: PHP register_globals Activation Vulnerability in parse_str() Release Date: 2005/10/31 Last Modified: 2005/10/31 Author: Stefan Esser [sesser (at) hardened-php (dot) net [email concealed]] Application: PHP4 <= 4.4.0 PHP5 <= 5.0.5 Severity: Unsafe termination of parse_str() may result in the register_globals directive turned back on Risk: Low Vendor Status: Vendor has released a bugfixed PHP 4 version References: http://www.hardened-php.net/advisory_192005.78.html Overview: PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. During the development of the Hardening-Patch which adds security hardening features to the PHP codebase, several vulnerabilities within PHP were discovered. This advisory describes one of these flaws concerning a weakness in the implementation of the parse_str() function. Under certain conditions triggering the memory_limit request shutdown during a parse_str() call will result in the core of PHP believing that the register_globals directive is turned on (for the rest of the lifetime of the involved webserver process). This may allow an attacker to exploit security flaws in PHP applications that exist due to uninitialised global variables. Details: 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 webserver 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 intialise it's variables. Proof of Concept: The Hardened-PHP project is not going to release exploits for any of these vulnerabilities to the public. Recommendation: It is strongly recommended to upgrade to the new PHP-Releases as soon as possible, because it also fixes a few vulnerabilities, that are rated critical. Additionally we always recommend to run PHP with the Hardening-Patch applied. GPG-Key: http://www.hardened-php.net/hardened-php-signature-key.asc pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1 Copyright 2005 Stefan Esser. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFDZh0ORDkUzAqGSqERAkJ8AKDJzbJ+v0YD7RQbePeFnUH6sgkSRQCgw82n Jwa8tdVX+CzgBbyVAuAAtbQ= =Qo+A -----END PGP SIGNATURE-----


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2020, cxsecurity.com

 

Back to Top