Sec Bug->Bug #81742 [Opn->Ver]: open_basedir bypass in SQLite3/pdo-sqlite extension by using url encoded file

Edit report at https://bugs.php.net/bug.php?id=81742&edit=1 ID: 81742 Updated by: cmb@php.net Reported by: bawolff at gmail dot com Summary: open_basedir bypass in SQLite3/pdo-sqlite extension by using url encoded file -Status: Open +Status: Verified -Type: Security +Type: Bug Package: SQLite related Operating System: all PHP Version: master-Git-2022-11-28 (Git) -Assigned To: +Assigned To: cmb Block user comment: N Private report: Y New Comment: > I'm a bit unclear if open_basedir bypass count as security bugs open_basedir bypasses are explicitly no security issues according to our classification[1]. Nonetheless, thanks for reporting! > Suggested fix: Probably easiest is to follow what pdo-sqlite > does and just ban file: uris when open_basedir is on. According to the discussion on the respective PDO_SQLite PR[2], this indeed appears to be prudent; although that may break some existing code relying on passing URL parameters. [1] <https://wiki.php.net/security#not_a_security_issue> [2] <https://github.com/php/php-src/pull/6610> Previous Comments: ------------------------------------------------------------------------ [2022-11-28 23:06:33] bawolff at gmail dot com 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. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=81742&edit=1