SQLite does not appear to prioritize malicious SQL CVEs. They surmise that an adversary that has already compromised an application to the extent of issuing arbitrary SQL must have many other avenues of control.
While SQLite earned DO-178B compliance status through a difficult test suite that appears to verify every branch instruction at the assembler/machine level, focus on hostile SQL is demonstrably not a priority.
Web applications are going to see hostile SQL, so this is a problem. I know that additional sandboxing was implemented in Chrome, but exploits always seem to find ways around.
A new implementation of SQLite, in Rust or Ada, that could spend more time on the safety of the parser because the various C foot-guns are removed, might have brought WebSQL to be, but that was a bridge too far.
When I hear of multiple CVEs described without details (or categorization), the phrase "Security Theatre" comes to mind.
Apparently, there is no formal oversight over how CVEs are reported or assigned severity. But because the label sounds official & authoritative & scary, people who spam CVEs are rewarded with clout.
Some have speculated that CVE inflation will lead to the death of the term altogether:
There is specific commentary on the SQLite CVE page that addresses WebSQL, which you might find enlightening:
"A few applications do allow untrusted SQL scripts received from potentially hostile agents to be run direct in SQLite. The main example of this is the Chrome and Safari web browsers, which allow an anonymous web page to run SQL using the WebSQL feature of Javascript. This is done inside a sandbox with tightly controlled constraints on resources, lest the SQL script try to soak up all available memory or CPU cycles in a denial-of-service attack. Chrome and Safari have the infrastructure in place to allow a hostile agent to run code which does not harm or compromise the rest of the machine. They have to, as they also run Javascript which could, if not tightly controlled, do even more damage than unrestrained SQL. Apart from Chrome and Safari, no applications known to the SQLite developers deliberately allows an anonymous remote agent to run arbitrary SQL text.
"However, most CVEs written against SQLite flippantly assume that an attacker is free to run any arbitrary SQL in the database engine. So to a good approximation, this means most CVEs written against SQLite really only apply to SQLite as it is used in Chrome and Safari. Or, in other words, most CVEs for SQLite do not apply to you unless you are one of the developers of Chrome or Safari."
Comments
SQLite does not appear to prioritize malicious SQL CVEs. They surmise that an adversary that has already compromised an application to the extent of issuing arbitrary SQL must have many other avenues of control.
https://www.sqlite.org/cves.html
While SQLite earned DO-178B compliance status through a difficult test suite that appears to verify every branch instruction at the assembler/machine level, focus on hostile SQL is demonstrably not a priority.
https://sqlite.org/th3.html#history
Web applications are going to see hostile SQL, so this is a problem. I know that additional sandboxing was implemented in Chrome, but exploits always seem to find ways around.
A new implementation of SQLite, in Rust or Ada, that could spend more time on the safety of the parser because the various C foot-guns are removed, might have brought WebSQL to be, but that was a bridge too far.
When I hear of multiple CVEs described without details (or categorization), the phrase "Security Theatre" comes to mind.
Apparently, there is no formal oversight over how CVEs are reported or assigned severity. But because the label sounds official & authoritative & scary, people who spam CVEs are rewarded with clout.
Some have speculated that CVE inflation will lead to the death of the term altogether:
https://news.ycombinator.com/item?id=25612429
There is specific commentary on the SQLite CVE page that addresses WebSQL, which you might find enlightening:
"A few applications do allow untrusted SQL scripts received from potentially hostile agents to be run direct in SQLite. The main example of this is the Chrome and Safari web browsers, which allow an anonymous web page to run SQL using the WebSQL feature of Javascript. This is done inside a sandbox with tightly controlled constraints on resources, lest the SQL script try to soak up all available memory or CPU cycles in a denial-of-service attack. Chrome and Safari have the infrastructure in place to allow a hostile agent to run code which does not harm or compromise the rest of the machine. They have to, as they also run Javascript which could, if not tightly controlled, do even more damage than unrestrained SQL. Apart from Chrome and Safari, no applications known to the SQLite developers deliberately allows an anonymous remote agent to run arbitrary SQL text.
"However, most CVEs written against SQLite flippantly assume that an attacker is free to run any arbitrary SQL in the database engine. So to a good approximation, this means most CVEs written against SQLite really only apply to SQLite as it is used in Chrome and Safari. Or, in other words, most CVEs for SQLite do not apply to you unless you are one of the developers of Chrome or Safari."
The CVEs are detailed, broadly in the parents comment (malicious / injected SQL) and more specifically in the links provided.