3 ms·

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.

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.

empthought 6y ago
RTFM https://www.sqlite.org/security.html https://www.sqlite.org/security.html
justinclift 6y ago
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 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/e1c5042f857e9fadc13eb0ff193f813103b2eef6/common/sqlite.go#L196-L226 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 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. :)

empthought 6y ago

RTFM https://www.sqlite.org/security.html https://www.sqlite.org/security.html

justinclift 6y ago

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 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/e1c5042f857e9fadc13eb0ff193f813103b2eef6/common/sqlite.go#L196-L226 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 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. :)