Req #79269 [NEW]: Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER
| From: | effulgentsia1 at gmail dot com | Date: | Thu, 13 Feb 2020 00:28:03 +0000 |
| Subject: | Req #79269 [NEW]: Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-225545@lists.php.net to get a copy of this message | ||
From: effulgentsia1 at gmail dot com
Operating system: All
PHP version: 7.3.14
Package: PDO SQLite
Bug Type: Feature/Change Request
Bug description:Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER
Description:
------------
PHP 7.4 unbundled the SQLite library, so benefits from how it was
compiled on the system. Many systems (Mac OSX, Debian, Ubuntu, and
others) compile it with SQLITE_MAX_VARIABLE_NUMBER=250000 or larger
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717900).
PHP 7.3 doesn't specify the flag
(https://github.com/php/php-src/blob/PHP-7.3/ext/sqlite3/config0.m4#L80),
so gets the low default of 999
(https://www.sqlite.org/limits.html#max_variable_number).
It would be helpful if PHP 7.3 could match the Debian number, to make
the test script work.
SQLite sets the default so low in order to prevent SQL injection attacks
from allocating excessive memory on low memory embedded systems
(https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg119067.html).
However, I don't think PHP is used on such systems, and a SQL injection
attack in a PHP application can already do far more harm than merely
allocating 18MB of memory (72 bytes * 250000).
I also filed a similar issue for Fedora
(https://bugzilla.redhat.com/show_bug.cgi?id=1798134).
Test script:
---------------
$large_array = range(0, 1000);
$db = new PDO('sqlite::memory:');
$placeholders = implode(', ', array_fill(0, count($large_array), '?'));
$stmt = $db->prepare("SELECT 1 WHERE 42 IN ($placeholders)");
var_dump($stmt->execute($large_array));
Expected result:
----------------
It should output "bool(true)", indicating that the execute() statement
executed.
Actual result:
--------------
It outputs nothing, because the execute() statement passes more
arguments than the 999 limit.
--
Edit bug report at https://bugs.php.net/bug.php?id=79269&edit=1
--
Fix committed: https://bugs.php.net/fix.php?id=79269&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=79269&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=79269&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=79269&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=79269&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=79269&r=support
Expected behavior: https://bugs.php.net/fix.php?id=79269&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=79269&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=79269&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=79269&r=globals
PHP version support discontinued: https://bugs.php.net/fix.php?id=79269&r=phptooold
Daylight Savings: https://bugs.php.net/fix.php?id=79269&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=79269&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=79269&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=79269&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=79269&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=79269&r=mysqlcfg