The SQLite Magellan Bug, And Your App
Recently, Tencent’s Blade Team published some notes about a bug that they call Magellan. The underlying flaw is in SQLite and its handling of full-text search “shadow tables” (FTS3, FTS4, etc.). An attacker that can either execute arbitrary SQL or give you an arbitrary database to use might be able to write arbitrary content to files via this bug. If that “arbitrary content” represents executable code, the attacker might be able to execute it. Hence, this is characterized by Tencent as a remote code execution (RCE) vulnerability.
Most Android apps should not be affected by this. Here are some categories of development techniques that might be at risk.
You Execute Arbitrary SQL from Arbitrary Sources
Many places are going to describe this as a Chromium (or Chrome) bug, rather than a SQLite bug. That is because Chromium offers WebSQL, allowing Web pages to create and manipulate relational databases on the client side… and Chromium’s WebSQL is implemented using SQLite.
Most Android apps that use SQLite execute their own SQL, whether hard-coded or generated via some library (e.g., Room). Few Android apps accept SQL statements from arbitrary sources and execute them. If you do, your app may be at risk.
At minimum, this bug could corrupt your app’s database or other accessible files. It is conceivable that an attacker could use this to remotely execute code, if your app executes arbitrary code. For example, if you use the support multidex library on Android 4.4 and older, in theory this attack could be exploited the way that Samsung was in 2015.
You Open Arbitrary Databases
It may be possible for an attacker to exploit this bug just using a SQLite database file that you open and attempt to use. This will be a more difficult avenue of attack. With WebSQL, not only do the attackers have the bug, but they have a full programming language (JavaScript) that they can use. With the arbitrary-SQL attack, attackers are limited to SQL expressions. With the arbitrary-database attack, attackers are limited to how your app uses the database. It is really unlikely that this will be able to be exploited.
That being said, if you allow the user to open a SQLite database that your app did not create, your app may be at risk.
SQLite’s “Defense Against Dark Arts”
page recommends that you run PRAGMA integrity_check or PRAGMA quick_check
on all foreign databases before doing anything else. Unfortunately, these were
added in SQLite 3.20.0, and so they are only available on Android 9.0 and higher,
at least in terms of the framework SQLite implementation.
You Use WebView to View Arbitrary Content
Android’s WebView supports WebSQL, apparently (I have not used it personally).
If you allow the user to view arbitrary Web content in a WebView, your app may be at risk.
If, however, you are only loading your own content (e.g., help pages packaged
as assets), you may be safe.
Google has the responsibility for updating WebView on newer Android versions
for Google Play ecosystem devices. Older devices (Android 4.x and below) will
be at risk indefinitely. Devices outside the Google Play ecosystem would need
to have their WebView implementations updated by their manufacturers or custom
ROM developers, presumably.
Depending on the nature of the app, you might consider trying to disable WebSQL
in WebView, if that is possible (again, I have no personal WebSQL experience here).
UPDATE 2018-12-18: Craig Russell points out that
setDatabaseEnabled() on WebSettings should control WebSQL access.
The specific bug here was fixed in SQLite 3.26.0. No current version of Android uses that — even Android 9.0 is back on 3.22.0. IMHO, it is very unlikely that Google would ship a replacement SQLite implementation in a security fix, and at this point I am not expecting to see an Android 9.1 release. So, most likely, the framework SQLite issue will not be fixed until the next major version of Android, in 2019.
If your app packages its own copy of SQLite, rather than use the framework copy, aim to upgrade to something based off of SQLite 3.26.0 or higher as soon as possible. For example, SQLCipher for Android 4.0.0 just shipped, but it is based on 3.25.2, so SQLCipher for Android users should keep an eye out for future updates.
The best collection of accessible information that I see about this bug is at this Hacker News page. My understanding is that the “SQLite” user there is Dr. Richard Hipp, the creator of SQLite.
