> -----Original Message-----
> From: Administrator Chat-Net [mailto:admin@xxxxxxxxxxx]
> Sent: Tuesday, November 01, 2005 12:33 AM
> To: phpsec@xxxxxxxxxxx
> Subject: [phpsec] phpBB Multiple Vulnerabilities
>
> Haven't seen this in the Mailinglist, too
>
> Security Advisory here:
>
> phpBB Changelog here:
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hardened-PHP Project
> www.hardened-php.net
>
> -= Security Advisory =-
>
>
>
> Advisory: phpBB Multiple Vulnerabilities
> Release Date: 2005/10/31
> Last Modified: 2005/10/31
> Author: Stefan Esser [sesser@xxxxxxxxxxxxxxxx]
>
> Application: phpBB <= 2.0.17
> Severity: Multiple vulnerabilities allow XSS, SQL injection
> and remote code execution
> Risk: Critical
> Vendor Status: Vendor has released an updated version
> References:
>
>
> Overview:
>
> Quote from www.phpbb.com:
> "phpBB is a high powered, fully scalable, and highly customizable
> Open Source bulletin board package. phpBB has a user-friendly
> interface, simple and straightforward administration panel, and
> helpful FAQ. Based on the powerful PHP server language and your
> choice of MySQL, MS-SQL, PostgreSQL or Access/ODBC database
> servers, phpBB is the ideal free community solution for all
> web sites."
>
> Because of our research into register_globals deregistration
> codes, the implementation within phpBB was audited and several
> weaknesses were found, that allowed to completely bypass the
> protection on PHP5 servers.
>
> After these weaknesses were found and disclosed to the vendor
> nearly 80 days ago, several problems with unitialised variables
> were discovered that allow XSS, SQL injection and even remote
> execution of arbitrary PHP code, when phpBB is used with
> register_globals turned on.
>
> While register_globals=off is the recommended setting, most web-
> hosters, even those that actually run PHP5, still have it
> enabled because it is their customers wish.
>
>
> Details:
>
> To get rid of possible security problems caused by not properly
> initialised variables phpBB comes with the following piece of
> code, that is intended to deregister global variables, which were
> created because of the register_globals directive. Unfortunately
> there are atleast 3 ways to bypass the protection.
>
> // PHP4+ path
> $not_unset = array('HTTP_GET_VARS', 'HTTP_POST_VARS',
> 'HTTP_COOKIE_VARS', 'HTTP_SERVER_VARS',
> 'HTTP_SESSION_VARS', 'HTTP_ENV_VARS',
> 'HTTP_POST_FILES', 'phpEx', 'phpbb_root_path');
>
> // Not only will array_merge give a warning if a parameter
> // is not an array, it will actually fail. So we check if
> // HTTP_SESSION_VARS has been initialised.
> if (!isset($HTTP_SESSION_VARS))
> {
> $HTTP_SESSION_VARS = array();
> }
>
> // Merge all into one extremely huge array; unset
> // this later
> $input = array_merge($HTTP_GET_VARS, $HTTP_POST_VARS,
> $HTTP_COOKIE_VARS, $HTTP_SERVER_VARS,
> $HTTP_SESSION_VARS, $HTTP_ENV_VARS,
> $HTTP_POST_FILES);
>
> unset($input['input']);
> unset($input['not_unset']);
>
> while (list($var,) = @each($input))
> {
> if (!in_array($var, $not_unset))
> {
> unset($$var);
> }
> }
>
> unset($input);
>
>
> Bypass Vulnerabilities
> ----------------------
>
> [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.
>
> [2] When the session extension is not started by a call to
> session_start(), PHP does not know about the variables
> $_SESSION or $HTTP_SESSION_VARS, which means, it is possible
> to fill them with any value if register_globals is turned on.
> Combined with the fact (that was even documented in the phpBB
> code), that array_merge() will fail in PHP5, when at least
> one of the parameters is not an array, it is possible for an
> attacker to simply set HTTP_SESSION_VARS to a string and let
> the complete protection fail, because $input ends up empty.
>
> [3] When register_long_array is turned off PHP does not know
> anymore about all the HTTP_* variables. This means they can
> be filled with anything that is completely unrelated to the
> existing global variables. It is obvious that the protection
> cannot work, when this configuration is choosen.
>
> Additonally to the 3 possible ways to bypass the globals
> deregistration code, several not properly initalised variables
> were disclosed to the vendor, that can even lead to remote code
> execution.
>
> Not properly initialised variables
> ----------------------------------
>
> [1] Within usercp_register.php the variable 'error_msg' is not
> properly initialised and can therefore be used to inject
> arbitrary HTML code
>
> [2] Within login.php the variable 'forward_page' is not properly
> initialised and can be used to inject arbitrary HTML code
>
> [3] Within search.php the variable 'list_cat' is not properly
> initialised and can be used to inject arbitrary HTML
>
> [4] Within usercp_register.php the variable 'signature_bbcode_uid'
> is not properly initialised and can be used for SQL injection
> of arbitrary 'field=xxx' statements into queries operating
> on the user table, when magic_quotes_gpc is turned off.
>
> [5] The same variable [4] can be used to inject f.e. the 'e'
> modifier into the first parameter of a preg_replace()
> statement, which means, that the second parameter is
> evaluated as PHP code. Because the second parameter is
> entirely filled with the user supplied signature, it is
> possible to execute any PHP code. This can be exploited,
> no matter if magic_quotes_gpc is turned on or off, just
> 2 different code paths need to be triggered.
>
>
> Proof of Concept:
>
> The Hardened-PHP project is not going to release exploits for any
> of these vulnerabilities to the public.
>
>
> Disclosure Timeline:
>
> 14. August 2005 - First contact with vendor through their
> security bugtracker.
> 30. October 2005 - Vendor released new version.
> 31. October 2005 - Public disclosure.
>
>
> Recommendation:
>
> It is strongly recommended to upgrade to the new phpBB release
> or to switch to another bulletin board application.
>
> You can get the new phpBB release at:
>
>
>
>
> GPG-Key:
>
>
>
> 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
>
> iD8DBQFDZWs2RDkUzAqGSqERAvFbAJ9ArGdOzvv2gcsAD0bbHgmcxkhXQQCgyplU
> ulFpBoL8zXpEsZA5m3TWopw=
> =u4eq
> -----END PGP SIGNATURE-----
>
> - Michael
>
