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 vulnerable. 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 bugs. 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 d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
