去年和今年的一些安全会议中，我曾经提出如果一些具有root权限的Android工具软件存在安全漏洞，也可能获得类似提权的利用效果。此前，我曾发文介绍过MIUI中定制的一款应用软件的组件暴露导致系统信息泄露。下面则是最近发现的另一个案例。

SQLite Editor是Speed Software开发的一款Android本地SQLite数据库文件查看器，在Google Play的购买和下载量为5万次以上。这些用户主要是Speed Software开发的另一款大名鼎鼎的工具Root Explorer带来。

当用户使用superuser类工具为SQLite Editor授予root权限后，使用它打开其他应用软件私有目录下的SQLite文件时，例如文件名为example.db，根据SuperSU Pro的记录，它会利用root权限将这个文件本身、这个文件的相关文件（包括可能存在的example.db-shm, example.db-wal, example.db-journal这三个文件）的other权限设置为可读和可写，然后以普通权限对该文件进行读取操作。在使用结束后，它会将example.db的other权限恢复为原来的值（通常为不可读、不可写）。但是，它忘了恢复example.db-journal的权限。因此，后者将继续保持other可读可写。这也就意味着，其他普通的应用软件现在开始也可以读写它了。

在Android中，example.db-journal文件是由SQLite透明地创建，用于缓存数据以便实现事务回滚机制。在我们的分析中，发现这类文件通常包含了大量example.db文件中存储的数据，包括但不限于用户的账户密码、用户的登陆token、用户的敏感隐私数据等。例如，我们知道Android的Email软件，以及老版本Android中的浏览器软件会将缓存的用户账号和密码明文地保存在本地的SQLite文件中。在其他一些涉及银行、支付等软件中，也会将登陆token存储在其私有目录下，受到Android安全机制的保护。然而，SQLite Editor的这一缺陷有可能导致这些密码或数据的缓存被所有其他软件读取。

这一问题的攻击面并不大，要成功利用它的前提条件非常多。但它已经足够作为典型案例，提醒Android系统中root权限工具的开发者以及系统的定制开发者，要更为严格地检查所写代码的安全性。

A .db-journal file becomes world readable and writeable

SuperSU Pro’s log of SQLite Editor’s root operations

In some of security conferences last and this year, I’ve said that, if any Android utility tool with root permission has security vulnerability, this may lead to gaining privilege-escalation like ability. In last year, I’ve posted a component exposing vulnerability in a MIUI’s custom application which will leaks system information. Here I’ll introduce another case I discovered recently.

The SQLite Editor is an Android local SQLite database file viewer developed by the Speed Software. In Google Play, it has been purchased and downloaded in more than 50,000 times. Most of its users are introduced by another famous application — the Root Explorer — which is also developed by the Speed Software.

When users give SQLite Editor a root permission by tools like superuser, and then open SQLite files in other applications’ private directories, for example, a file named example.db, according to SuperSU Pro’s log, SQLite Editor will uses its root persmission to change the ‘other’ permission of this file and its related files (include may existings example.db-shm, example.db-wal and example.db-journal) to readable and writeable, and then read or write it by normal permission. After its operations finish, it will restore the ‘other’ permission of example.db to its original value (normally, unreadable and unwriteable). But, it forget to restore example.db-journal’s permission! Thus, the last file will keep readable and writeable by ‘other’ Linux users, which means, it can be read or wrote by other normal applications.

In the Android system, files like example.db-journal are transparently created by the SQLite library, and used for transaction roll back. By our analysis, we found that these files will contain huge content which belong to the ‘example.db’ files, include users’ account password, login token and sensitive privacy data. For example, we all know that the Email in Android and the Browser in old versions’ Android will plaintextly store users’ account and password. In other banking or payment applications’ databases, there’ll be login token and other information. These data should be protected by Android’s security mechanisms. However, this flaw of SQLite Editor will lead these cache of password or data to be read by other applications.

Of course, attack surface of this flaw isn’t wide. It need many pre-requirements to exploit it. But it’s enough to be a typical case to reminder root permission tools developers and system customization developers to more strictly check the security of their code.

A .db-journal file becomes world readable and writeable

SuperSU Pro’s log of SQLite Editor’s root operations