Note that the vulnerable extension is only enabled in the sqlite shell:
> However, the generate_series extension is only enabled by default in the shell binary and not the library itself, so the impact of the issue is limited.
I'm not sure why you are surprised. I'm pretty sure almost all serious dbs attempt this (although some have a permission model to attempt it).
In sqlite there is the load_extension() function but it is disabled by default. In some situations you can use attach to write a file with a name that is meaningful to something else on your system.
Other than those two things (and assuming no weird extensions are loaded) i think it would be very big news if you found a way to execute code from an sqlite query.
> attach to write a file with a name that is meaningful to something else on your system.
Yes, this is what I meant, e.g. writing to ~/.bash_profile or so. Forbidding queries to do something like this could have a large negative effect on the capability of the database engine to its users.
I mean, just writing to ~/.bash_profile wont work as i assume it needs to be executable. (I assume it wont work if the file already exists since it expects to be a valid db if it exists).
In practise, finding an actual path to write to that actually gets code to execute might be tricky in the context of a unix user used just for one specific sqlite backed service.
Sqlite also has an option to disable the attach keyword (SQLITE_LIMIT_ATTACHED). It is very rare to get sql injection at the beginning of the query so in practise this usually isn't an issue (although i guess that was your point).
> I mean, just writing to ~/.bash_profile wont work as i assume it needs to be executable.
It does not. It's an RC file sourced by the shell, not a script.
> It is very rare to get sql injection at the beginning of the query so in practise this usually isn't an issue (although i guess that was your point).
Yes. Would also be required to use these vulnerabilities.
I sure hope they do. Security doesn't end at the gates, so to speak. It starts there. We need layered security to create systems where not every hack has critical impact.
Yet SQL injection is still a thing. Any vuln that can promote an SQL injection to an RCE is very bad.