> On Dec 20, 2018, at 5:05 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> Which would make it do what ? I can imagine "crash with a memory fault". I
> find it much harder to believe "execute code stored in the database". You
> would have to know a lot about a program to make it do that, and an attack
> aimed at one program/library (e.g. Chromium) wouldn't work on another with a
> different memory layout.
It depends on the details of the vulnerability. Since it’s an FTS3 query that
triggered the problem, there are probably multiple FTS3 and SQLite stack frames
active at the time the buffer overrun occurs, so it may not depend so much on
the application itself. (Of course it would likely depend on the compiler, the
optimization settings, and of course CPU architecture.)
Again, from Dr. Hipp’s statement:
By making malicious changes to the shadow tables that FTS3 uses and
then running
FTS3 queries that used those tables, an integer overflow could cause a
buffer overrun, which if carefully managed might lead to an RCE.
This is only a problem for application that enable FTS3 (using the
SQLITE_ENABLE_FTS3 or SQLITE_ENABLE_FTS4 compile-time options) and
which allow potential attackers to run arbitrary SQL.
Anyway, my original question was: If an application opens untrusted SQLite
databases as documents, and if a trigger added to a database can run arbitrary
SQL, wouldn’t that make such an application vulnerable?
—Jens
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
