[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 it’s 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/