Comment by roelschroeven
5 years ago
If I use libpng or libjpeg to decode an image and that causes a buffer overrun or another security vulnerability, that is very much a bug in libpng or libjpeg.
The same is true when I open a database in SQLite: if that causes a security problem, it's a bug in that library. I don't even see how you could validate a database file before you hand it over to SQLite.
The exploit mentioned above relies on third party functions being loaded into the database. eg application specific functions
Those functions have to be explicitly loaded by the application after loading the database. eg: They're not stored in the database and loaded with it.
You'd validate the database (past the standard integrity checking), by loading it and not adding any third party functions. Then check it's not doing anything dodgy with views, or outright disable views. Then load the third-party extensions (if needed).
If you wanted to go even further, you could also add an authorizer callback function:
https://www.sqlite.org/c3ref/set_authorizer.html
That's called (multiple times) any time a SQL statement is prepared/executed, and catches things like functions being run, tables being accessed, etc. You can use that to only allow a whitelisted set of functions to run, which would help in some scenarios. eg:
https://github.com/sqlitebrowser/dbhub.io/blob/e1c5042f857e9...
The "Defense Against Dark Arts" page on the SQLite website has further good info about this:
https://www.sqlite.org/security.html
As a data point, I implemented the above "Defense against Dark Arts" stuff recently for an online SQLite data publishing platform to let people run free form queries on databases (dbhub.io). It wasn't all that hard to implement. Much less so that I'd been expecting. :)
RTFM
https://www.sqlite.org/security.html