Even a project like SQLite with a huge amount of testing / dynamic analysis tooling applied to it still has serious vulnerabilities caused by memory corruption bugs.
sqlite.org/testing.html
It's important to make a small TCB for these kinds of issues.
Conversation
That claim sounds implausible - the memory usage patterns should not be a function of untrusted input.
1
SQLite still has memory corruption bugs. A subset of those are vulnerabilities. I can link to some of the recent ones, but I don't feel that's necessary. I don't see how it's implausible that C code is still going to have edge cases not totally handled leading to mem corruption.
1
I think it sounds more plausible that someone thought "you feed a corrupt sqlite db file to it" is a CVE, when accepting untrusted db files is not the intended usage.
1
That is the intended usage of SQLite. That's part of the threat model for it in the real world and it certainly aims to be safe in that case. It's also supposed to remain memory safe with a lot of attacker control over the database queries.
1
1
sqlite.org/whentouse.html
SQLite does not compete with client/server databases. SQLite competes with fopen().
It's intended for all kinds of structured data, including configuration files and things like thumbnail caches. It's the goal of the project to be used like that.
1
1
Data owned by the same user/privilege context that reads it. You should not be sharing this kind of data between privilege contexts regardless of the format it's in.
1
Only data in standard serialized formats for transmission should be shared between privilege contexts. Ever.
1
SQLite is intended to be a standard serialized format for transmission. Please read through sqlite.org/whentouse.html. It's intended to be used for things like an implementation of the file format for GIMP or a word processor. It's not trying to be an alternative to MySQL.
1
1
Then that's an obviously bad intent incompatible with their security policy. Nobody should be using db files for information interchange.
2
What do you mean incompatible with their security policy? They have one of the strongest attempts at writing correct and safe C code that I've seen in any project. They have extensive testing and fuzzing of the database format including applying dynamic analysis features.
If you mean this quote: twitter.com/vyodaiken/stat. That quote is explaining that running arbitrary SQL is not supposed to be safe even if language features are disabled. In the next paragraph, it speaks about *confidence* in the handling of untrusted database files in contrast.
This Tweet is unavailable.
1
1
And it is true that they do a great job limiting the attack surface, writing clear / simple code and applying amazingly thorough testing that I've never seen in any other open source project. If SQLite's approach to security with C is not good enough then it's clearly not doable.
1
1
Show replies