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).
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.
