> -----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
> -= 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: http://www.hardened-php.net/advisory_172005.75.html
> 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.
> 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,
> while (list($var,) = @each($input))
> if (!in_array($var, $not_unset))
> Bypass Vulnerabilities
>  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.
>  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.
>  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
> Not properly initialised variables
>  Within usercp_register.php the variable 'error_msg' is not
> properly initialised and can therefore be used to inject
> arbitrary HTML code
>  Within login.php the variable 'forward_page' is not properly
> initialised and can be used to inject arbitrary HTML code
>  Within search.php the variable 'list_cat' is not properly
> initialised and can be used to inject arbitrary HTML
>  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.
>  The same variable  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.
> 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:
> 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
> -----END PGP SIGNATURE-----
> - Michael