Req #79269 [Opn->Wfx]: Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER
| From: | nikic@php.net | Date: | Tue, 22 Dec 2020 16:52:55 +0000 |
| Subject: | Req #79269 [Opn->Wfx]: Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-231222@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=79269&edit=1
ID: 79269
Updated by: nikic@php.net
Reported by: effulgentsia1 at gmail dot com
Summary: Bundled SQLite is compiled without
SQLITE_MAX_VARIABLE_NUMBER
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: PDO SQLite
Operating System: All
PHP Version: 7.3.14
Block user comment: N
Private report: N
New Comment:
7.3 is no longer actively supported, 7.4 has unbundled sqlite, so this issue is no longer
applicable.
Previous Comments:
------------------------------------------------------------------------
[2020-02-13 19:47:36] effulgentsia1 at gmail dot com
I also opened https://bugs.php.net/bug.php?id=79272 as a related
issue.
------------------------------------------------------------------------
[2020-02-13 00:28:03] effulgentsia1 at gmail dot com
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 this bug report at https://bugs.php.net/bug.php?id=79269&edit=1