Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
SQLite3: add DEFENSIVE config option for SQLite >= 3.26.0 #3709
This is a new option, available in SQLite starting from 3.26.0 that is meant to prevent any corruption of the database file that could come from arbitrary crafted SQL queries.
From the SQLite doc:
Please note that this could potentially cause BC-breaks if code was writing to sqlite_dbpage, the schema or shadow tables. It is quite unlikely that any PHP code would do that kind of thing IMHO, and if it does I don't think it should be allowed by default.
! BUT another case where it might break things is if you had exported a backup of the DB with SQL statements that would rewrite to the shadow tables. This would be the case for example for database management tools, eg. PHPLiteAdmin. In that case it might be suitable to find a different solution, eg. adding an extra param to the open method to allow disabling the defensive mode. This is open to discussion, if anyone has a better idea I'll try to find some free time to do another PR :)
Also, it is likely that the recent RCE in SQLite is due to users being able to write to shadow tables. See https://news.ycombinator.com/item?id=18685296
cmb69 left a comment
Well, it seems to me that the simplest and most secure solution would be to call
We also should consider whether to apply this enhancement to older branches. At least having it in PHP-7.3 appears to be sensible.
Hi - I'm confused by the PR, as I can't see where db_obj is going to be defined where it is used in the changed code: https://github.com/php/php-src/pull/3709/files#diff-d0d9591d093d64f6c62abd62271485baR2417
Also, reading the docs for the defensive flag, at https://www.sqlite.org/c3ref/c_dbconfig_defensive.html#sqlitedbconfigdefensive is says it is to be used by sqlite3_db_config().
Reading the docs for that https://www.sqlite.org/c3ref/db_config.html it says:
So this flag is settable per connection, rather than a module wide setting.
If that's the case I would recommend:
Apologies if this is all me just misreading the code....heads a bit fuzzy...
You are not misreading the code, my head was fuzzy when I did this apparently, it's fixed, thank you!
It is another way of using it, but I guess a hosting provider will want to set that for all the code running on the server, with no way for userland code to disable it, as it might lead to security issues affecting other customers such as this RCE. So a system INI setting seems better suited.