Description:
------------
[I'm a bit unclear if open_basedir bypass count as security bugs, given how many warnings are on that config option]

The fix for https://bugs.php.net/bug.php?id=77967 is incorrect. This checks for file: uri's, and then checks if they meet open_basedir restrictions. However, SQLite supports hex escapes in file urls, including as a directory separator. PHP doesn't take this into account, which allows you to use relative urls to escape open_basedir to read sqlite files outside of the basedir as well as write files.

Note: for the PDO_sqlite extension (instead of sqlite3) this was incidentally fixed in a8dd009f23a. I don't think people realized that the fix fixed a pre-existing open_basedir bypass and as a result it was not backported.

Suggested fix: Probably easiest is to follow what pdo-sqlite does and just ban file: uris when open_basedir is on. Otherwise would have to decode the uri being sure to do it the same way sqlite does. I would also suggest backporting the change to pdo_sqlite to all supported versions.

Test script:
---------------
<?php
ini_set( 'open_basedir', '.' );
// Works on php master
$db = new SQLite3(':memory:');
$a = $db->query( "ATTACH 'file:..%2ffoo.php' as db2;" );

// Works prior to a8dd009f23a
$db = new PDO('sqlite::memory:');
$a = $db->exec( "ATTACH 'file:..%2ffoo.php' as db2;" );


Expected result:
----------------
I expect an error to happen.

e.g. Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 23 not authorized in test.php:4

Actual result:
--------------
foo.php is created in the parent directory.