Bug #54169 [Com]: Garbage Pointers returned for (n)varchar(max) columns (SQL Server)
| From: | jlongo at kastle dot com | Date: | Wed, 27 May 2015 00:05:08 +0000 |
| Subject: | Bug #54169 [Com]: Garbage Pointers returned for (n)varchar(max) columns (SQL Server) | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-192906@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=54169&edit=1
ID: 54169
Comment by: jlongo at kastle dot com
Reported by: auroraeosrose@php.net
Summary: Garbage Pointers returned for (n)varchar(max)
columns (SQL Server)
Status: Assigned
Type: Bug
Package: PDO ODBC
Operating System: Any
PHP Version: Irrelevant
Assigned To: auroraeosrose
Block user comment: N
Private report: N
New Comment:
@trapper - it isn't necessarily a "problem" in ODBC... it is a change in behavior for
Microsoft's ODBC Driver 11 implementation. As of ODBC Driver 11, they are returning the length
as 0 for max fields. They used to return a very large number for the column size, such as 2147483647
when running on a 32 bit platform, when using varchar(max) fields in prior versions of their driver.
As an effect, the pure odbc extension will also need this kind of update to work with
Microsoft's ODBC Driver 11 and max fields.
Previous Comments:
------------------------------------------------------------------------
[2015-05-26 23:53:07] jlongo at kastle dot com
Hey guys... this bug has been sitting for far too long IMO. This needs to be identified as a
security issue. The garbage pointers that I get back when testing this flaw more times than not
will contain the contents of the script source that I am running. I have verified that the patch
that was submitted works, so really it should just be a matter of folks merging it into the
supported PHP versions for the next patch release.
------------------------------------------------------------------------
[2015-02-05 18:38:52] trapper at coremr dot com
This bug is still in the latest version of PHP at this moment (5.6). It affects all the versions of
the SQL Server Native Client ODBC drivers and makes them unfeasible to use because of it.
As its a problem inside ODBC, it is currently affecting both raw odbc_* functions as well as any PDO
connections.
------------------------------------------------------------------------
[2013-01-28 16:16:20] a dot schilder at gmx dot de
This bug is really evil and should be treated as a security issue.
In one case I got the content of a previously loaded PHP file instead of the requested field data,
so it's possible that the content of sensitive files is returned and shown.
------------------------------------------------------------------------
[2011-05-12 10:58:33] bugs dot php at pixbox dot co dot uk
I'm experiencing the same issue, using PHP 5, a Microsoft SQL Server 2008, and a
direct ODBC connection.
My workaround was to alter the nvarchar(max) columns to nvarchar(n) where n is
whatever the suitable size for that column was, or text.
The really strange thing was that when it was returning gibberish, it returned
snippets of PHP code from the page that ran the query!
------------------------------------------------------------------------
[2011-03-05 17:06:22] auroraeosrose@php.net
Description:
------------
I found an issue this week that exists in both odbc and pdo_odbc with
SQL Server. The ODBC implemention of Windows returns 0 as the length
for for varchar(max) and nvarchar(max). This makes the allocation of
the strings incorrect and you get back garbage pointers for the
contents.
This was a pretty easy fix for pdo_odbc, simply check if the colsize
is returned as 0 and the type is one of the varchar types, if so
always treat it as a column with "long" data. This works perfectly
without breaking things. Attached is a patch that works for both 5.3
and trunk, includes an additional test for the issue.
ODBC shows the same issue - don't have a fix for that
Occurs in all versions of PHP
There are multiple bug reports concerning this and related to it - I'll try to gather them all
up (later)
Test script:
---------------
$db = new PDO('odbc:yourdsnhere', 'username', 'password');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->exec('CREATE TABLE testing(id INT NOT NULL PRIMARY KEY, data varchar(max))');
$insert = $db->prepare('INSERT INTO testing VALUES (?, ?)');
$insert->execute(array(1, str_repeat('i', 500)));
$stmt = $db->query('select * from testing');
var_dump($stmt->fetchAll());
unset($db, $insert, $smt);
// This shows the same issue in odbc
$db = odbc_connect ('yourdsnhere', 'username', 'password');
$stmt = odbc_exec($db, 'select * from testing');
var_dump(odbc_fetch_array($stmt));
Expected result:
----------------
array(1) { [0]=> array(4) { ["id"]=> string(1) "1" [0]=> string(1)
"1" ["data"]=> string(500)
"iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii"
[1]=> string(500)
"iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii!
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii"
} }
Same for the odbc call
Actual result:
--------------
array(1) { [0]=> array(4) { ["id"]=> string(1) "1" [0]=> string(1)
"1" ["data"]=> string(500)
"�-\p-\!������ËòE�������ii����iiii!���!���select
* from
foo�iiiiii���!�������hall�iiiiiii!������ÃùE�������ii��������1���!���Â|a���ìòEáE����ðE��������stmt����!���1���(áE����������������1���!�������������������`óEà õE$E
©"���1���1�����������ÂóE����à õE������������â¬ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½1���1�������������������óE�������@éEøëE���!���1���à óE����������������!���iiiiiiiiiiiiiiiiiiiiiiiiiii!
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" [1]=>
string(500)
"�-\p-\!������ËòE�������ii����iiii!���!���select
* from
foo�iiiiii���!�������hall�iiiiiii!������ÃùE�������ii��������1���!���Â|a���ìòEáE����ðE��������stmt����!���1���(áE����������������1���!�������������������`óEà õE$E
©"���1���1�����������ÂóE����à õE������������â¬ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½1���1�������������������óE�������@éEøëE���!���1���à óE����������������!���iiiiiiiiiiiiiiiiiii!
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii!
iiiiiiiiiiiiiiiiiiiiiiiiiii" } } array(2) { ["id"]=> string(1) "1"
["data"]=> string(500)
"�èE8öEp�����HöEHöE$.\päE����icrosoft][SQL
Server Native Client 10.0]String data, right
truncation���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ï¿!
½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½"
}
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=54169&edit=1