Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104439
To: "Christoph M. Becker" <cmbecker69@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 15 Feb 2019 15:54:11 +0100
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <46354329-38ca-82a2-352d-71394e0ce6bd@gmx.de>
References: <46354329-38ca-82a2-352d-71394e0ce6bd@gmx.de>
Message-ID: <71ffeb615565a73f4f267eacd2a4180c@bohwaz.net>
User-Agent: Roundcube Webmail/1.1.5
Subject: =?UTF-8?Q?Re=3A_=5BPHP-DEV=5D_Mitigate_=E2=80=9CMagellan_vulnera?=  =?UTF-8?Q?bilitites=E2=80=9D_in_PHP_7=2E2=3F?=
From: php@bohwaz.net (BohwaZ/PHP)

Thanks Christoph!

Just to be clear, this patch doesn't prevent security issues if you 
don't update your SQLite3 library, it just implements a new option 
available in newer SQLite versions which will prevent arbitrary changes 
to the internals of a SQLite database only if you SQLite3 library is 
3.26+. Changing the internals of a SQLite database is something that 
should be quite rare in the real world I think.

This addresses potential security issues for PHP applications allowing 
end-users to run arbitrary SQL queries.

But please note that if your application does allow end-users to run 
arbitrary SQL queries, I advise that you limit them to read-only by 
either:

* opening the database as readonly (available in PDO since PHP 7.3: use 
open attribute: PDO::SQLITE_ATTR_OPEN_FLAGS => PDO::SQLITE_READONLY)
* using the SQLite3Stmt::readOnly method (will tell you if a prepared 
statement will write to the database)
* or using the equivalent for PDO:

$st = $pdo->prepare('SELECT * FROM table;');
var_dump($st->getAttribute(PDO::SQLITE_ATTR_READONLY_STATEMENT));

This last one should be available in PHP 7.4 I hope? See 
https://github.com/php/php-src/pull/2760

Both PDO features are currently undocumented but it's on my TODO list as 
well.

If your users are performing custom SELECT queries, this is the best 
thing to do.

I am now working on bringing support for a userland custom callback to 
the SQLite3 authorizer API, this will allow PHP code to restrict access 
to specific tables, columns and operations, that should also improve 
security in the future.

As a side note, although my time is quite limited, I have worked for the 
last two years to improve features support and security of the SQLite3 
extension and try to match features of the SQLite3 extension in PDO as 
well.

I have to give a warm thank you to Christoph and everyone else who 
helped me in this :)
And if anyone is interested in helping me improve SQLite support in PHP 
you are more than welcome :)

Cheers.