[php<=5.4.3] Parsing Bug in PHP PDO prepared statements may lead to access violation Affected Product: PHP Affected Component: PDO - PHP Data Objects Affected Versions: <=5.4.3 (latest version and trunk) PHP Bug Ref: #61755 Patch: bug61755.diff Discovery Date: Feb 2012 Advisory Date: 2012-06-10 Description: ------------ Inconsistent parsing of PHP PDO prepared statements. Erroneous design of parsers state machine. Under special circumstances parsing of prepared statements does not stop leading in cycling the whole stack without terminating on \0. This leads to access violations, accessing of stack data, DoS. Bug Description: ---------------- There are several design errors in the state-machine responsible for parsing PHP PDO based statement objects. These errors are based on the state-machines inability to consistently check the supplied SQL-Query. Under special circumstances an attacker is able to force the responsible PDO code to iterate beyond the termination of the supplied query string resulting in a buffer out of bounds access. This access may lead to uncontrollable as well as attacker controllable behavior and Access Violations caused by the code iterating the whole stack and trying to access addresses beyond the stack end. In very unlikely and constructed environments it may also be possible to force parameter rebinding of prepared statements - even though some context specific input filtering is applied - by utilizing the stack cycling behavior of the state machine. This can be accomplished by 1) pushing a manipulated SQL string containing fake parameter bindings (:named:, ?) onto the stack (e.g. using post variables) 2) manipulating the main SQL query string (see preconditions) to make the pdo_parser cycle the stack 3) until it cycles into the fake query previously pushed to stack where the magic happens. This forces the state machine into cycling into random stack data and then into the previously pushed manipulated SQL string with fake parameter bindings. To finalize this attack the manipulated SQL string then terminates the SQL parsing resulting in rebinding of prepared parameters. The attacker needs to know the original binding names (for named parameters) and the number of bound params for this attack to succeed. This scenario is unlikely to occur but as usual in computer security this may be used in conjunction with other attacks to multiply the impact. Preconditions: -------------- * PDO is used to access the DB * For remote attacks: User must be able to directly control any part of the query string prior its preparation (stm->prepare()). We are well aware that this is a general coding fault which leads to other security relevant implications but sadly enough its also quite common in many frameworks, projects to use prepared statements with user controlled data instead of binding them after preparation. State-Machine Graph, Test-Scripts, Traces, PoCs are available. Vendor Response: ---------------- * Patch 2012-04-19 (bug61755.diff) (see php bugref) Patch available, but still not fixed in 5.4.3 (latest) Timeline: --------- * 2012 Feb - Discovered in 5.3.8, verified for 5.3.0/5.3.10 and 5.4.0 * 2012 March - Responsible Disclosure via SSD/BeyondSecurity * 2012 April - Patch available 2012-04-19 * 2012 May/June - No trace of bugfix in svn for 5.3/5.4/trunk although mentioned in bugref #61755 * 2012 June - No trace of bugfix in svn for 5.3/5.4/trunk, code ... * 2012 June - public disclosure CREDITS: -------- Discovered by 0x721427D8 via BeyondSecurity - SecuriTeam Secure Disclosure Refs: ----- http://php.net/ http://www.php.net/manual/en/intro.pdo.php http://svn.php.net/viewvc/php/php-src/trunk/ext/pdo/ http://www.securiteam.com/