phpBB Multiple Vulnerabilities

Credit: Stefan Esser
Risk: High
Local: No
Remote: Yes

Hardened-PHP Project Security Advisory Advisory: phpBB Multiple Vulnerabilities Release Date: 2005/10/31 Last Modified: 2005/10/31 Author: Stefan Esser [] 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 "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:

Vote for this issue:


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 2018,


Back to Top