The work is impressive, but I wish Google wouldn't try so hard to claim to be the world first at everything. This claim feels extremely unprincipled:
> We believe this is the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software. Earlier this year at the DARPA AIxCC event, Team Atlanta discovered a null-pointer dereference in SQLite, which inspired us to use it for our testing to see if we could find a more serious vulnerability.
Every word in "public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software" applies to the Team Atlanta finding that they are citing too, and the Team Atlanta finding was against an actual release version of SQLite instead of a prerelease. If either team has provided the first example of this convoluted sentence, it is Team Atlanta, not Google.
It is possible that they're arguing that the Team Atlanta finding wasn't "exploitable", but this is very debatable. We use CVSS to rate vulnerability impact, and CVSS defines Availability (crashing) as an equal member of the [Confidentiality, Integrity, Availability] triad. Being able to crash a system constitutes an exploitable vulnerability in that system. This is surely especially true for SQLite, which is one of the most mission-critical production software systems in the entire world.
But if we're going to act like we're being very precise about what "exploitable" means, we should conclude that neither of these are exploitable vulnerabilities. To exploit them, you have to provide malicious SQL queries to SQLite. Who does that? Attackers don't provide SQL queries to SQLite systems -- the developers do. If an attacker could provide arbitrary SQL queries, they can probably already exploit that SQLite system, through something like an arbitrary file content write to an arbitrary local filename into RCE. I don't think either group found an exploitable vulnerability.
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.
I couldn't believe this, even all the poorly-defined qualifiers, given maximal charity, don't really help.
The whole thing has the scent of "we were told to get an outcome, eventually got it, and wrote it up!" --- I've never ever read a Project Zero blog post like this,* and I believe they should be ashamed of putting glorified marketing on it.
* large # of contributors with unclear contributions (they're probably building the agent Google is supposed to sell someday), ~0 explication of the bug, then gives up altogether on writing and splats in selected LLM responses.
* disclaimer: ex-Googler, only reason it matters here is I tend to jump to 'and this is a corruption of Google' because it feels to me like it was a different place when I joined, but either A) it wasn't or B) we should all be afraid of drift over time in organizations > 1000 people
> We believe this is the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software. Earlier this year at the DARPA AIxCC event, Team Atlanta discovered a null-pointer dereference in SQLite, which inspired us to use it for our testing to see if we could find a more serious vulnerability.
Every word in "public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software" applies to the Team Atlanta finding that they are citing too, and the Team Atlanta finding was against an actual release version of SQLite instead of a prerelease. If either team has provided the first example of this convoluted sentence, it is Team Atlanta, not Google.
It is possible that they're arguing that the Team Atlanta finding wasn't "exploitable", but this is very debatable. We use CVSS to rate vulnerability impact, and CVSS defines Availability (crashing) as an equal member of the [Confidentiality, Integrity, Availability] triad. Being able to crash a system constitutes an exploitable vulnerability in that system. This is surely especially true for SQLite, which is one of the most mission-critical production software systems in the entire world.
But if we're going to act like we're being very precise about what "exploitable" means, we should conclude that neither of these are exploitable vulnerabilities. To exploit them, you have to provide malicious SQL queries to SQLite. Who does that? Attackers don't provide SQL queries to SQLite systems -- the developers do. If an attacker could provide arbitrary SQL queries, they can probably already exploit that SQLite system, through something like an arbitrary file content write to an arbitrary local filename into RCE. I don't think either group found an exploitable vulnerability.