lol there's a bug but we're not telling you
Remote code execution vulnerability in SQLite
51–60 of 161 posts
Re: Remote code execution vulnerability in SQLite
#52Earlier quoted context omitted.
Isn't that the definition of branch testing, to test all possible branches within code and also testing the logic in all of those branches?
You test all possible executions of your program when you test with all possible data inputs, which is infinite.
That is why I like using random data generators for tests. You can input some static data and then the rest is random. Every once in a while a bug pops out when you see a test fail that was previously passing.
Re: Remote code execution vulnerability in SQLite
#53Earlier quoted context omitted.
SQLite can by principle not suffer from a RCE.
Not sure why this is being downvoted, but you're correct. Now, a networked application that exposes some level of access to sqlite? That's another story. The question I think we all are asking is just how much "leg" does sqlite have to show to be vulnerable?
It's a pretty silly definition; it's like saying PDF or JPEG parsers can't be vulnerable to RCE, when they are in fact major vectors for RCE attacks.
Re: Remote code execution vulnerability in SQLite
#54Earlier quoted context omitted.
You test all possible executions of your program when you test with all possible data inputs, which is infinite.
That is why I like using random data generators for tests. You can input some static data and then the rest is random. Every once in a while a bug pops out when you see a test fail that was previously passing.
SQLite is heavily subjected to fuzzing already ... maybe this vulnerability was discovered that way.
Re: Remote code execution vulnerability in SQLite
#55Python ships with a sqlite3 module in the standard library. Does this mean Python needs to ship a security path? What should Python users be doing about this?
But does the sqlite3 module actually contain SQLite with it, or just a library to interface with it? The fix does not change any interface library code.
Re: Remote code execution vulnerability in SQLite
#56SQLite is the most thoroughly tested codebase I'm aware of [1]. It has seven times more test code than non-test code. 100% branch coverage. If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code. [1] https://www.sqlite.org/testing.html
Especially considering you could generate faster C code than written by hand. With Proofs, Without Compromises http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP1...
Re: Remote code execution vulnerability in SQLite
#57SQLite is the most thoroughly tested codebase I'm aware of [1]. It has seven times more test code than non-test code. 100% branch coverage. If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code. [1] https://www.sqlite.org/testing.html
Especially considering you could generate faster C code than written by hand. With Proofs, Without Compromises http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP1...
Have you seen the language Esterel?
Re: Remote code execution vulnerability in SQLite
#58An RCE in a non-networked component is interesting (in other words, obvious hyperbole). Either this is your usual corruption bug/vuln triggerable in some/many programs using SQLite, or an actual bug in SQLite itself, e.g. query preparation (a fix/workaround being committed to SQLite doesn't necessarily imply one or the other). Whether the RCE hyperbole is justified remains to be seen. Edit: Apparently the exploit vec…
They mention the example of browsing to a web page. Not quite a fully fledged remote execution bug but close enough. I think what they're really saying is they're aware of remote execution cases. An example of that might be a web services that's backed by a SQLite query.
Drive-by code execution from a page in a web browser is almost the textbook example of "RCE" in its modern sense.
Re: Remote code execution vulnerability in SQLite
#59Earlier quoted context omitted.
Isn't that the definition of branch testing, to test all possible branches within code and also testing the logic in all of those branches?
Consider a line like: value = 1 / input; You can get "100% coverage" if you test that with `input = 1`, but unless you check with `input = 0` you're missing a quite important logical check.
Not really - internally inputs 0 and 1 use different branches.
Re: Remote code execution vulnerability in SQLite
#60Python ships with a sqlite3 module in the standard library. Does this mean Python needs to ship a security path? What should Python users be doing about this?
It's only an issue if you allow untrusted code to run arbitrary SQL statements, which should never be done.