Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?
[deleted]
Remote code execution vulnerability in SQLite
31–40 of 161 posts
Re: Remote code execution vulnerability in SQLite
#32[deleted]
Re: Remote code execution vulnerability in SQLite
#33SQLite 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.
Re: Remote code execution vulnerability in SQLite
#34SQLite 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
SQLite can by principle not suffer from a RCE.
Re: Remote code execution vulnerability in SQLite
#35Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?
They are giving time to more SQLite users to patch and waiting the CVE to be assigned. Looking at the chromium patch, this has something to do with ALTER TABLE. Looking at SQLite release notes they clearly are hiding the real nature of the issue there. For instance, see this: https://www.sqlite.org/lang_altertable.html "Compatibility Note: The behavior of ALTER TABLE when renaming a table was enhanced in versions 3.2…
I think it relates to "ALTER TABLE" too-- specially: https://www.sqlite.org/src/info/6e1330545e7b74fe
The comments in checkin a61ed147 for "renameColumnFunc()" give me the willies.
Re: Remote code execution vulnerability in SQLite
#36Remote implies it can be accessed remotely, is that true, or did they mean “remote if an attacker can remotely send data to SQLite”?
Re: Remote code execution vulnerability in SQLite
#37SQLite 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
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
Re: Remote code execution vulnerability in SQLite
#38SQLite 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
SQLite can by principle not suffer from a RCE.
[deleted]
Re: Remote code execution vulnerability in SQLite
#39An 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.
JavaScript code has access to SQLite. So any webpage where the attacker controls/can inject JavaScript is vulnerable.
Re: Remote code execution vulnerability in SQLite
#40My guess, for what it's worth, is that chromium is vulnerable because it exposes sqlite to web applications, which can then execute queries in such a way as to achieve code execution.
I highly doubt this would affect, say, a blog running with a sqlite database. From the alarmist nature of this post, though, it's unclear.
I see chromium, in their patch, switched to using new flags when opening the DB. There are also some sqlite changes that seem to prevent meddling with virtual table shadow tables (eg inverted index for the fts3 extension).
The question I think everyone is asking is how much sqlite needs to be exposed by an application in order to be vulnerable?
Just my thoughts. Eager to learn more.