"Attackers don't provide SQL queries to SQLite systems -- the developers do."
Yet SQL injection is still a thing. Any vuln that can promote an SQL injection to an RCE is very bad.
Yet SQL injection is still a thing. Any vuln that can promote an SQL injection to an RCE is very bad.
> 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.
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.
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).
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.