Comment by empthought
5 years ago
This is a security flaw of the system or application using SQLite, though. It is trusting data it should not trust and executing code provided with that data.
5 years ago
This is a security flaw of the system or application using SQLite, though. It is trusting data it should not trust and executing code provided with that data.
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
Huh? If you're using SQLite as an application file format, isn't opening untrusted files a key use case? What else, never share files with people? That must be a pretty boring application.
Sure but just like a web browser, it’s the application’s responsibility to sandbox or verify the code, not the http library’s.
That translates to "don't use SQLite", right?
How would an application that uses SQLite as a file format be able to scan for malicious database files that trigger buffer overflows in the SQLite engine? I'm really not sure what you're suggesting.
1 reply →
From the description, I didn't watch the video, loading the database and querying it is enough to run the exploit. To compare with your example, it would be like having a remote exploit if your application queries a specific http endpoint.
For sure application developers could sandbox the http library, sqlite, or stop using libraries developed in so unsafe programming languages but it's a bit too early for that.