On 12/18/18, Dominique Devienne <ddevie...@gmail.com> wrote:
> https://blade.tencent.com/magellan/index_en.html
> Sounds to me it more related to a "remote callable" program like Chrome,
> than SQLite proper, but I'd like an official stance on SQLite itself please.

There was a bug in FTS3 (not in the SQLite core) that allowed an SQL
Injection to escalate into a Remote Code Execution (RCE).  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.  Contrary to
published reports, there are probably *not* millions of application
that meet those circumstances.  In fact, I only know of one:  Chrome.
Chrome has FTS3 enabled, and allows arbitrary SQL through the WebSQL
interface.  On the other hand, Chrome only allows this within a
sandbox, so as far as I know, the problem did not lead to an exploit
even in Chrome.  Perhaps there were other techniques used for escaping
the sandbox after executing the RCE against FTS3, but if not then the
attack against Chrome was also benign, as far as I know.

I believe that Safari also enables WebSQL, but unless I am mistaken,
Safari has disabled FTS3 and so it is probably not vulnerable.

The Fossil Version Control System can be configured to allow anonymous
users to enter SQL to generate bug-report summaries.  However, that
SQL is very restricted.  Only SELECT statements are allowed, and they
are only allowed to access specific tables.  So Fossil is not

I am not aware of any other applications that deliberately run SQL
from anonymous sources

In any application that enables FTS3 and also has an SQL Injection
bugs, the magellan problem allows those SQL Injection bugs to escalate
to an RCE bug.   And so, the FTS3 bug makes a preexisting SQL
Injection bug worse, but does not introduce any new bugs.

The bug in FTS3 was fixed in version 3.26.0.  So if you are using
SQLite 3.26.0, then you are not vulnerable to this RCE even if you do
enable FTS3 and do allow SQL Injections.

Our policy with respect to bugs is to try to not only fix the bug, but
also fix the process.  Hence, when this issue was discovered in FTS3,
we tried to figure out what we could have done differently from the
beginning to have prevented this bug in the first place, and what we
could do differently moving forward to prevent future similar bugs.
As part of that analysis, we came up with the new
SQLITE_DBCONFIG_DEFENSIVE option.  Applications that do deliberately
allow anonymously-sourced SQL can enable SQLITE_DBCONFIG_DEFENSIVE to
prevent the SQL from deliberately corrupting the database file.  By
preventing corrupt database files, the attack surface is reduced.  Had
this option been available before Magellan, and had Chrome used it
(the latest Chrome releases *do* use it, I am told) then the Magellan
bug would have never happened.  But SQLITE_DBCONFIG_DEFENSIVE is not
the "fix" for the bug.  It is defense-in-depth against similar future

We are hard at work on additional defense-in-depth measures now.  I do
not know of any other exploits against FTS3 or SQLite or any other
common SQLite extensions.  But we are working to make sure no new ones
are discovered.

D. Richard Hipp
sqlite-users mailing list

Reply via email to