Eliminating 90% of memory corruption bugs with clean, well-written C code and proper usage of tooling like UBSan and ASan isn't good enough or comparable to providing memory safety. Full memory safety can be provided for C without proving all the code formally correct.
Conversation
Either write it in a subset with annotations specifically to take advantage of memory safety verification (which would not be far from what you want to write naturally in clean code most of the time, but with some adjustments and annotations) or have the compiler do it.
1
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.
2
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.
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.
1
Show replies